Intended Architecture Deep Dive

Architecture Overview

Intended is a governance runtime for AI agent operations. Its job is to classify what an AI agent wants to do, evaluate whether the agent should be allowed to do it, enforce the decision cryptographically, and record everything in a tamper-evident ledger.

The architecture has five primary components: the Connector Gateway, the Intent Compiler, the Authority Engine, the Token Service, and the Audit Ledger. Each component is independently deployable and horizontally scalable. Here is how they fit together.

Request Flow

A governance decision follows this path through the system.

An external event arrives at the Connector Gateway. This might be a webhook from GitHub, an API call from an agent SDK, or an event from a Kubernetes admission controller. The gateway authenticates the request, validates the format, and routes it to the Intent Compiler.

The Intent Compiler transforms the raw request into a classified intent object. It identifies the domain, category, and action type. It enriches the intent with agent metadata, environmental context, and resource information. The classified intent is forwarded to the Authority Engine.

The Authority Engine evaluates the intent against applicable policies. It calculates a risk score across eight dimensions. Based on the policy evaluation and risk score, it determines the outcome: allow, allow-with-conditions, escalate, or deny. If the outcome is allow, it requests a token from the Token Service.

The Token Service generates a cryptographic authority token. The token includes the intent ID, action type, resource identifier, nonce, TTL, and any conditions. The payload is signed with the authority signing key. The token is returned to the Authority Engine, which returns it to the caller.

At execution time, the agent presents the token to the execution layer (connector or target system integration). The execution layer sends the token to the Token Service for verification. The Token Service checks the signature, TTL, nonce, and action match. If valid, it marks the nonce as consumed and returns a verification success.

Throughout this flow, every step is recorded in the Audit Ledger. The intent, the classification, the policy evaluation, the risk score, the token issuance, the token verification, and the execution outcome are all recorded as hash-chained entries.

Component: Connector Gateway

The Connector Gateway is the ingestion layer. It receives events from external systems and routes them to the Intent Compiler.

**Responsibilities.** Authentication (API key, mTLS, JWT). Request validation (schema compliance, field ranges). Rate limiting (per agent, per domain, per organization). Protocol translation (HTTP, gRPC, WebSocket). Load shedding (reject requests when system is at capacity).

**Design decisions.** The gateway is stateless and horizontally scalable. Each instance handles approximately 5,000 requests per second. The gateway does not perform any governance logic; it is purely an ingestion and routing layer. This separation ensures that changes to governance logic do not require gateway redeployment.

**Technology.** Built on a lightweight HTTP framework with middleware for authentication and validation. TLS termination at the gateway for external traffic. Internal traffic between gateway and compiler uses mTLS.

Component: Intent Compiler

The Intent Compiler transforms raw agent requests into classified intent objects.

**Responsibilities.** Field extraction from raw requests. Domain classification. Category and action type classification. Confidence scoring. Enrichment with agent metadata and environmental context. Multi-intent decomposition for compound requests.

**Design decisions.** The compiler uses a hybrid classification approach: pattern matching for common request formats (70 percent of traffic) and a lightweight model for novel expressions (30 percent). This hybrid approach minimizes latency for the common case while handling the long tail of unusual requests.

The compiler is stateless. It reads agent metadata and resource information from the shared data store (via cache) but does not maintain any session state. Each classification request is independent.

**Performance.** Median latency: 10 milliseconds. P99 latency: 25 milliseconds. Throughput: 2,000 classifications per second per instance.

Component: Authority Engine

The Authority Engine is the core governance runtime. It evaluates classified intents against policies and determines governance outcomes.

**Responsibilities.** Policy matching (determining which policies apply to a given intent). Policy evaluation (evaluating the matched policies against the intent). Risk scoring (calculating the composite risk score across eight dimensions). Outcome determination (mapping the policy result and risk score to a governance outcome). Condition generation (for allow-with-conditions outcomes, determining the specific conditions).

**Design decisions.** The engine uses a compiled policy representation. When policies are created or updated, they are compiled into a decision tree that can be evaluated without parsing the policy source. This compilation step happens once per policy change and is cached. Runtime evaluation traverses the pre-compiled tree, which is significantly faster than interpreting the policy source for every request.

Risk scoring is pluggable. The default scoring model uses a weighted average across eight dimensions, but organizations can provide custom scoring functions for specific domains or use cases.

The engine is stateless. It reads policies from the policy store (via cache) and agent metadata from the agent store (via cache). The only write operation is forwarding the decision to the Audit Ledger.

**Performance.** Median latency: 5 milliseconds (cache hit). P99 latency: 20 milliseconds. Throughput: 3,000 evaluations per second per instance.

Component: Token Service

The Token Service handles cryptographic token operations: issuance, verification, and revocation.

**Responsibilities.** Token generation (creating signed tokens with nonce, TTL, and conditions). Token verification (validating signature, TTL, nonce, and action match). Nonce management (recording and checking consumed nonces). Key management (signing key rotation, key storage, HSM integration).

**Design decisions.** The Token Service maintains a nonce ledger for replay protection. The ledger is partitioned by token prefix for horizontal scaling. Nonce consumption is an atomic operation (check + mark in a single transaction).

Signing keys are stored in the platform's key management system (AWS KMS, HashiCorp Vault, or a local HSM for on-premise deployments). The Token Service never holds the raw signing key in memory; signing operations are delegated to the KMS.

Key rotation is automated. New signing keys are generated on a configurable schedule (default: 90 days). Old keys are retained for verification of tokens issued before rotation. Keys are retired (unable to verify) after a configurable grace period (default: 180 days).

**Performance.** Token issuance: median 8 milliseconds (dominated by KMS signing). Token verification: median 3 milliseconds (signature verification is local; nonce check is a fast lookup).

Component: Audit Ledger

The Audit Ledger is the tamper-evident record of all governance events.

**Responsibilities.** Record ingestion (receiving governance events from all other components). Hash chain maintenance (computing and storing chain hashes). Record persistence (writing to durable storage with serializable transactions). Chain verification (validating chain integrity on demand). Evidence export (generating compliance-ready exports in JSON, PDF, and CSV).

**Design decisions.** The ledger uses PostgreSQL with serializable transaction isolation. This ensures that hash chain entries are strictly ordered and that concurrent writes do not create chain inconsistencies.

Records are batched for write efficiency. The default batch window is 50 milliseconds. Records are collected in an in-memory buffer, the batch hash chain is computed, and the batch is written in a single transaction. This reduces transaction overhead by 10-50x compared to per-record writes.

The ledger supports partitioned storage. Records older than a configurable retention period (default: 2 years) are archived to cold storage. The hash chain remains intact across the partition boundary: the first record in the hot partition references the last record in the cold partition.

**Performance.** Write throughput: approximately 10,000 records per second (batched). Chain verification: approximately 50,000 records per second (read-only, parallelizable).

Data Store

Intended uses PostgreSQL as its primary data store for policies, agent metadata, organization configuration, and audit records. The choice of PostgreSQL is deliberate.

Serializable transaction isolation is critical for the audit ledger. PostgreSQL supports true serializable isolation, not just snapshot isolation labeled as serializable.

Mature replication for read scaling. PostgreSQL's streaming replication provides low-latency read replicas for policy and metadata reads.

Broad deployment support. PostgreSQL runs on every major cloud platform, on-premise, and in air-gapped environments. This is important for Intended's multi-deployment-model strategy.

Ecosystem. Extensions like pg_partman (for time-based partitioning), pgcrypto (for cryptographic operations), and pg_stat_statements (for query performance monitoring) are battle-tested and well-supported.

Caching Layer

Intended uses a two-level caching strategy. The first level is an in-process cache within each component instance, using a bounded LRU cache with configurable TTL. The second level is a shared Redis instance for data that is expensive to compute and shared across instances.

Cache invalidation uses a pub/sub pattern. When a policy, agent, or configuration is updated, a cache invalidation message is published. All component instances subscribe to the invalidation channel and evict the affected cache entries.

Security Architecture

All internal communication uses mTLS. Each component has its own certificate, issued by an internal CA. Certificate rotation is automated.

Secrets (database credentials, API keys, signing keys) are stored in the platform's secret management system and injected at runtime. Secrets are never committed to code or configuration files.

The Authority Engine processes intent metadata, not the underlying data that agents access. Customer data does not pass through Intended's infrastructure in the standard deployment model. This minimizes the data classification burden and simplifies compliance.

Deployment Architecture

Intended is deployed as a set of Kubernetes Deployments (or containers on bare metal for on-premise). Each component has its own Deployment with independent scaling parameters. The Connector Gateway scales based on ingestion throughput. The Intent Compiler scales based on classification throughput. The Authority Engine scales based on evaluation throughput. The Token Service scales based on token operations. The Audit Ledger scales based on write throughput.

A typical enterprise deployment runs 3-5 instances of each component, with autoscaling configured to add instances during traffic spikes. The entire stack can run on as few as 5 containers for development and testing.

This architecture has served us well from our earliest prototypes through our largest enterprise deployments. The key properties -- stateless components, horizontal scaling, defense-in-depth security, and tamper-evident audit -- are not afterthoughts. They are the foundation.