Every Agent Decision Follows the Same Path. Only One Step Has No Infrastructure.
Every business decision follows the same sequence: context arrives, policy applies, a decision is made, an action executes. Data has had infrastructure for decades — databases, warehouses, pipelines. Workflow has had infrastructure for decades — orchestrators, queues, task systems. The policy step has had nothing. Rules live in system prompts, Confluence pages, manager judgment, and spreadsheets that someone updates when the policy changes.
That gap was manageable when humans made decisions. Humans had context, institutional memory, and a manager to call. AI agents have none of those things. They have whatever you put in the system prompt. When the prompt is wrong, outdated, or silent on an edge case, the agent guesses — consistently, at agent speed, until someone notices the pattern.
Polidex is the policy infrastructure — and the gate AI agents can't bypass. It sits between the agent and the action, evaluates the applicable rules, issues a signed authorization, and governs what the agent is permitted to do. No valid authorization, no action. This page walks through the decision flow.
System Components
Four components, defined roles. The agent sends a request and receives a decision. Polidex fetches authoritative context from source systems directly, evaluates the policy rules, and issues a signed token. The connector enforces the token against the downstream system. The agent never touches the context that drives the decision.
AI Agent
Source Systems
CRM · HRIS · CMDB · ITSM
Polidex Policy Engine
evaluates rules · resolves decision · issues token
Decision Token
signed · versioned · tamper-evident
Polidex Connector
enforces token scope · holds credentials
Downstream System(s)
CRM · ITSM · fulfillment · email
Every path the agent takes to a downstream system runs through the policy engine first. The token is the record that the policy ran — not a log of what the agent said, but a signed artifact of what it was authorized to do.
The Decision Flow, Step by Step
1. The agent sends a request via MCP
The agent does not guess or interpret. It sends a structured query to Polidex via MCP — the request type, the relevant identifiers, what was asked. MCP is the agent-native interface: the agent uses a Polidex tool the same way it uses any other capability in its environment, and receives a resolved answer it can act on directly.
2. Polidex fetches authoritative context
Polidex does not rely on the agent for context. It fetches authoritative data directly from source systems using its own integrations: account tier from the CRM, order history from the OMS, entitlements from the HRIS. The agent never assembles or passes this data. It cannot alter the facts the policy decision runs on.
3. The policy engine evaluates the rules
Polidex evaluates the query against the current published policy version. It resolves the decision — authorized, denied, or escalate — and returns the result with the authorization path, the policy version that applied, and the action scope the agent is permitted to take. The agent receives a resolved answer, not a policy table to interpret.
4. A decision token is issued
The resolved decision is cryptographically signed and returned as a decision token: a structured, tamper-evident record of what was authorized, which policy version applied, and when. This is the audit artifact. It exists before the agent acts, not after — and it cannot be altered.
5. The connector enforces scope and executes
The connector holds the credentials to downstream systems. It reads the token, enforces the action scope it specifies, and executes against the downstream system. The agent cannot act beyond what the token authorizes. This is the gate: the connector will not execute without a valid token, and the agent cannot reach downstream systems directly. The execution is logged against the token record, creating a complete chain from query to action.
Organizations integrating via REST rather than MCP can use the same policy engine — the same decision envelope (status, authorization path, policy version, action scope) comes back regardless of which interface you use.
Go Deeper on Each Component
Each layer in the system has a dedicated page. Start with the component that matters most to the question you're trying to answer.
MCP is what makes the policy query native to the agent's environment — not a bolt-on middleware call, but a discoverable tool the agent uses the same way it uses any other capability. When the policy layer is the MCP server the agent calls, there is no path around it.
The policy engine evaluates the query against versioned business rules and returns a resolved decision. It is not a guardrails filter and not a general-purpose BRMS — it is a structured evaluation layer that returns what the agent is authorized to do, which rule applied, and why.
The decision token is a cryptographically signed record of what was authorized at the moment of evaluation. It is the audit artifact — not the conversation log, which records what the agent said, but the token, which proves what it was authorized to do.
Every rule in Polidex is versioned. Every decision record references the policy version active at decision time. When a customer disputes a decision from three months ago, you can retrieve the exact rule that applied — not reconstruct it from memory.
When the policy engine returns “escalate,” the exception routes through a defined approval path — not to a human who improvises, but to a governed workflow with approval options, time limits, and an automatic audit trail. Exceptions are a defined policy type, not cases that fall outside the policy.
The policy gate runs before the agent acts. It governs what the agent can do, issues the signed authorization that downstream systems require, and produces the record that proves it — before, not after. No valid authorization, no action.