AI control plane
Control the systems that act for you.
PSIFI Lattice gives engineering and security teams a unified control plane for observing, governing and operating production AI agents, models and tools.
Agent → Model → Tool → Policy → Action → Audit
PSIFI Lattice — conceptual map of a governed action path. 13 nodes and 14 connections. Customer agent, a agent in production, connects to Primary model. Finance agent, a agent in production, connects to Primary model and Reasoning model. Research agent, a agent in staging, connects to Reasoning model. Primary model, a model in routed, connects to CRM tool and Refund API, through a allow gate and approval gate. Reasoning model, a model in routed, connects to Knowledge index, through a allow gate. CRM tool, a tool in read, connects to CRM. Refund API, a tool in write, connects to Approver. Knowledge index, a data in read, connects to Warehouse. Approver, a human in finance ops, connects to Payments. CRM, a system in system of record, connects to Audit ledger. Payments, a system in financial, connects to Audit ledger. Warehouse, a system in analytics, connects to Audit ledger. Audit ledger, a policy in append only, terminal node.
- Agent
- Model
- Tool
- Data
- Human
- System
- Policy gate
02The problem
Your AI stack is becoming a system.
Production AI now spans agents, models, tools, data, APIs, policies and human approvals. Each part is owned by a different team and observed by a different tool.
The problem is no longer model intelligence. Once a system can take an action, the operational questions are about control.
- 01Who can act?Permissions
- 02What can they access?Scope
- 03What happened?Traces
- 04What was blocked?Policy
- 05What did it cost?Cost
- 06Who approved it?Audit
On the left, seven parts of an AI stack — agents, models, tools, data, APIs, policies and humans — sit in separate dashed outlines with unconnected edges and open questions. As the section progresses they move together into a single framed lattice in which every part is connected through policy, labelled one operational control surface.
03The PSIFI thesis
Intelligence can generate the action.
Infrastructure must control the action.
PSIFI Lattice sits between AI systems and the systems they act upon. It does not decide what an agent should do. It decides what an agent is permitted to do, records what it did, and holds the consequential actions for a human.
FIG. 03 — Every action crosses the control plane before it reaches a system of record.
05The product
See the entire AI system.
One map of every agent, the models it calls, the tools it can use, the data it reads and the policies that stand between them. Switch the overlay to change what the same map tells you.
Live lattice map — agents, models, tools, data and the systems they act upon. 13 nodes and 14 connections. Customer agent, a agent in prod · low risk, connects to General large. Research agent, a agent in staging · low risk, connects to Reasoning mid. Finance agent, a agent in prod · medium risk, connects to General large and Reasoning mid. General large, a model in provider a, connects to CRM tool and Knowledge index and Refund API, through a allow gate and allow gate and approval gate. Reasoning mid, a model in provider b, connects to Knowledge index and Ledger database, through a allow gate and redact gate. CRM tool, a tool in read, connects to CRM. Knowledge index, a data in vector store, connects to Warehouse. Ledger database, a data in read, connects to Warehouse. Refund API, a tool in write, connects to Approver. CRM, a system in system of record, terminal node. Warehouse, a system in analytics, terminal node. Approver, a human in finance ops, connects to Payments. Payments, a system in financial, terminal node.
- Agent
- Model
- Tool
- Data
- Human
- System
- Policy gate
OVERLAY · POLICY — gates shown on every governed edge, with the policy that applies
- 09:41:07tool.call · payments.refund.create◐ approval
- 09:41:06model.call · general-large● allow
- 09:41:04tool.call · crm.customer.read● allow
- 09:41:02tool.call · erp.invoice.read● allow
- 09:40:58tool.call · email.send✕ deny
- 09:40:55vector.query · knowledge_v3● allow
- 09:41:07P-014 · refund above threshold◐ approval
- 09:40:58P-031 · outbound email to new domain✕ deny
- 09:40:55P-021 · pii redaction applied● allow
- 09:40:31P-014 · refund below threshold● allow
No node selected
Select any node in the lattice map to see its identity, environment, permissions and recent activity.
Amber ticks mark policy events · scrub to reconstruct the map at that moment
FIG. 04 — Command Center. All entities, activity and figures on this screen are illustrative.
06Signature demonstration
Watch an agent execute.
An autonomous refund request, from the customer message to the sealed audit event. The policy step is the one that matters: the action is held before it reaches the payment system.
Arrow keys move between completed steps · Enter or click selects
Nothing has executed yet
Run the simulation to watch a governed action travel the lattice: agent, model, tool, policy, approval, action and audit.
07The five control layers
Five layers. One operating surface.
Observe, govern, approve, optimize and audit are not separate products. They are one path that every governed action travels, in that order.
Reconstruct any action after the fact.
Each governed action leaves an append-only record: the actor, the action, the policy version that applied, the approver if there was one, and the result the target system returned.
who
finance_approver
what
payments.refund.create
when
2026-01-14 09:41:10.402
why
P-014 v4 · amount above threshold
result
rfd_0d93aa · 402 ms
- 09:41:07P-014 · refund above threshold◐ approval
- 09:40:58P-031 · outbound email to new domain✕ deny
- 09:40:55P-021 · pii redaction applied● allow
- 09:40:31P-014 · refund below threshold● allow
08Product ecosystem
One control plane. Connected layers.
Lattice is the control plane. Relay routes model traffic beneath it and Sentinel enforces policy at the agent boundary above it. Relay and Sentinel are on the roadmap and are not available.
FIG. 05 — Sentinel at the agent boundary, Lattice as the control plane, Relay on the model path.
09Agent inventory
Agents are infrastructure. Manage them like it.
An agent has an owner, an environment, a risk classification, a set of tools it may reach, the models it routes to, the policies attached to it and an operating cost. That makes it an asset, not a script.
| Agent | Status | Owner | Risk | Last execution | Cost · 30d |
|---|---|---|---|---|---|
| Invoice Resolution Agent agt_invoice_resolution | ● PRODUCTION | Finance Automation | MEDIUM | 2 min ago | ₹18,240 |
| Customer Resolution Agent agt_customer_resolution | ● PRODUCTION | Support Automation | HIGH | 14 s ago | ₹42,900 |
| Research Agent agt_market_research | ◐ STAGING | Knowledge Platform | LOW | 6 min ago | ₹7,120 |
| Release Notes Agent agt_release_notes | ○ DEVELOPMENT | Developer Experience | LOW | 3 h ago | ₹410 |
| Ticket Triage Agent agt_ticket_triage | ● PRODUCTION | Support Automation | LOW | 38 s ago | ₹11,650 |
| Vendor Onboarding Agent agt_vendor_onboarding | ◐ STAGING | Procurement Ops | MEDIUM | 22 min ago | ₹2,980 |
Swipe → for more columns
Invoice Resolution Agent
agt_invoice_resolution
- owner
- Finance Automation
- environment
- production
- risk
- MEDIUM
- last execution
- 2 min ago
- runs · 24h
- 1,204
- cost · 30d
- ₹18,240
Tool permissions
- erp.invoice.read● ALLOW
- billing.api.write◐ APPROVAL
Models
- general-largerouted
Attached policies
- Finance Refund PolicyACTIVE
- PII redactionACTIVE
10Policy engine
Write the boundary once. Enforce it everywhere.
A policy is a condition and an action. Because it is evaluated at the boundary rather than inside the prompt, it applies whatever the model decided to do.
Move the test amount below ₹50,000 to watch the decision change.
Prevent autonomous refunds above ₹50,000
When
transaction.type=refund
AND
transaction.amount>50000
Then
require_human_approval
Scope
Finance Agents · Production
Evaluation preview
{
"transaction": {
"type": "refund",
"amount": 82400
}
}Decision
◐ approval required
matched P-014 · amount above ₹50,000
- v4threshold raised to ₹50,00011 Jan
- v3scope narrowed to finance agents04 Jan
- v2action changed to require_human_approval28 Dec
- v1created in observe-only mode21 Dec
11Approval center
Keep a human on the decisions that matter.
The held action arrives with the trace, the context and the exact call attached — enough to decide without opening four other systems. Approve or reject below; both write an audit event.
Refund request
Customer Resolution Agent
₹82,400
- policy
- P-014 · high-value financial action
- risk
- HIGH
- waiting
- 2 min
- approver role
- finance_approver
- sla
- 30 min · 12 min remaining
Pending action
POST /v1/refunds
{
"order": "ORD-40218",
"amount": 82400,
"currency": "INR",
"reason": "damaged_on_arrival"
}Context
Order ORD-40218 · delivered 11 Jan · two prior support contacts · no previous refunds on this account.
Agent reasoning summary
Customer reported damage on arrival with photographic evidence attached to the ticket. Refund matches the order total.
No decision recorded in this session yet.
12Cost intelligence
Know what every agent costs to run.
Spend attributed to the agent, the model and the tool that produced it, with event markers for the changes that moved the line. All figures on this screen are illustrative.
Show values as a table
| Day | Spend (₹ thousands) |
|---|---|
| 1 | 22 |
| 2 | 25 |
| 3 | 24 |
| 4 | 28 |
| 5 | 31 |
| 6 | 30 |
| 7 | 34 |
| 8 | 33 |
| 9 | 38 |
| 10 | 41 |
| 11 | 39 |
| 12 | 44 |
| 13 | 48 |
| 14 | 46 |
| 15 | 52 |
| 16 | 50 |
| 17 | 55 |
| 18 | 58 |
| 19 | 54 |
| 20 | 61 |
| 21 | 59 |
| 22 | 64 |
| 23 | 68 |
| 24 | 66 |
| 25 | 71 |
| 26 | 74 |
| 27 | 72 |
| 28 | 78 |
| 29 | 81 |
| 30 | 84 |
Executions per day, thousands · illustrative
general-large₹54,300
reasoning-mid₹21,880
embedding-small₹7,120
Small multiples rather than a stacked area, so each model is readable on its own scale.
Next 30 days
₹96,400
Projected from the current 30-day trend and the execution volume of the last seven days. Shown as a dashed continuation on the spend chart.
- basis30d linear trend
- confidenceillustrative only
- driversvolume · model mix
13How it works
From first connection to full control.
Four stages on one path. Telemetry flows in from the boundary, policy is evaluated at the boundary, and operators work from what the boundary recorded.
A single horizontal path. On the left, four ingest surfaces — SDK, gateway, MCP and OTLP — feed stage one, Connect. The path continues through stage two, Observe, then crosses a policy gate at stage three, Control, and ends at stage four, Operate, before reaching enterprise systems.
14Developer experience
Built for the teams shipping AI.
One call does the work that matters: ask whether this action may proceed, and honour the answer. Everything else — traces, cost attribution, the audit record — follows from it.
- Python SDKInstrument agents and wrap tool calls.Designed
- TypeScript SDKNode and edge runtimes, same event model.Designed
- REST APIAgents, policies, approvals, traces, audit.Designed
- OpenTelemetrySend existing spans over OTLP.Designed
- MCP connectivityGovern tools exposed over Model Context Protocol.Designed
- API keysScoped keys per environment.Designed
- WebhooksApproval requests and policy events.Designed
fromfromimport psifi import Latticelattice = Lattice(api_key=osos.environ["PSIFI_API_KEY"])# Register the agent once, at startup.agent = lattice.agent( id="invoice-resolution", environment="production", owner="finance-automation",)# Wrap the consequential call. Lattice evaluates policy# before the request reaches the payment system.withwith agent.run(trace="tr_8f21c4") asas run: decision = run.guard( tool="payments.refund.create", payload={"order": order_id, "amount": 82_400}, ) ifif decision.requires_approval: run.wait_for_approval(decision.approval_id) ifif decision.allowed: payments.refunds.create(order=order_id, amount=82_400)FIG. 08 — Guarding a consequential call. The policy decision is returned before the request reaches the payment system.
15Architecture
A control plane, drawn honestly.
Seven layers, from the operator in a browser to the system of record an agent can change. The interesting one is layer six: the boundary where an action is intercepted.
Holds the agent registry, evaluates policy, routes approvals and appends audit records.
In: evaluation and registration requests. Out: decisions, approval requests, audit events.
FIG. 07 — Designed architecture. Select a layer for its responsibility, inputs and outputs.
| Layer | Design choice | Component | Why |
|---|---|---|---|
| Frontend | Static build behind a CDN | CDN | Console assets cached at the edge |
| API | Container infrastructure | Containers | Horizontally scaled, stateless request handling |
| Data | PostgreSQL | PostgreSQL | Registry, policies, approvals, audit ledger |
| Events | Queue / streaming | Queue | Telemetry ingest decoupled from query |
| Telemetry | Object storage + search | Object store + search | Span payloads with configurable retention |
| Cache | Redis | Redis | Policy compilation and hot lookups |
| Secrets | Secrets management | Secrets manager | Provider credentials and API keys |
| AI | Model providers / cloud AI | Model providers | Reached through the gateway, never stored |
| Monitoring | OpenTelemetry / cloud monitoring | OpenTelemetry | The control plane is itself observable |
Swipe → for the full table
16Security
Control is part of the architecture.
Identity decides who the actor is. Policy decides whether the action may happen. The audit record makes both reconstructable. None of that is a setting applied afterwards.
01
Identity
02
Policy
‖ evaluate
03
Agent
04
Tool
‖ permission
05
Action
06
Audit
‖ record
- 01EncryptionTransport encryption in flight and encryption at rest for stored telemetry and records.Designed
- 02Tenant isolationWorkspace-scoped data paths, with logical isolation as the default and private deployment as an option.Designed
- 03RBACRoles for engineers, approvers, auditors and administrators, scoped per environment.Designed
- 04SSOEnterprise identity through SAML or OIDC, with group-to-role mapping.Designed
- 05Audit logsAppend-only records for agent actions, policy changes and approval decisions.Designed
- 06Secrets managementProvider credentials and API keys held in a secrets manager, never in telemetry.Designed
- 07Data redactionField and pattern redaction applied before payloads are stored or sent to a model.Designed
- 08Retention controlsPer-workspace retention windows for traces, payloads and audit records.Designed
No certification is claimed on this site. Security documentation is available on request.
17Use cases
Where control matters.
Five operations where an AI action has a consequence. Each row shows the path an action takes and the capability that holds it.
18Integrations
Connects to the systems you already run.
Categories rather than logos. Nothing here is presented as a completed integration unless it is marked available — and at this stage, none are.
Models
Model providers reached through the gateway.
- Hosted model providersDesigned
- Cloud AI servicesDesigned
- Self-hosted inferenceRoadmap
- Embedding providersDesigned
Infrastructure
Where the control plane runs.
- AWSDesigned
- AzureDesigned
- GCPDesigned
- Private deploymentRoadmap
Business systems
Systems an agent can change.
- CRMDesigned
- ERPDesigned
- Support deskDesigned
- CommunicationRoadmap
Developer systems
Engineering surfaces.
- Git providersDesigned
- REST APIsDesigned
- DatabasesDesigned
- CI pipelinesRoadmap
AI infrastructure
The agent runtime itself.
- MCP serversDesigned
- Vector storesDesigned
- Inference endpointsDesigned
- OpenTelemetryDesigned
Available · connected today · Designed · interface defined · Roadmap · planned, not built
19Pricing
Priced on what you operate.
The meter is the governed action, not the seat. Published prices are not available yet; the drivers and the tier boundaries are.
Pricing available on request.
| Driver | DeveloperFor experimentation. | TeamFor production teams. | BusinessFor organisations requiring governance. | EnterpriseFor private deployment and advanced controls. |
|---|---|---|---|---|
| Monitored AI eventsThe primary meter: governed actions and captured spans. | Included allowance | Scales with volume | Scales with volume | Custom |
| EnvironmentsDevelopment, staging and production separation. | 1 | 3 | Unlimited | Unlimited |
| Telemetry retentionHow long traces and payloads are queryable. | Short | Standard | Extended | Custom |
| UsersConsole seats, including approvers and auditors. | 1 | Team | Organisation | Organisation |
| Policy engineConditions, actions and scopes. | Basic | Full | Full | Full |
| Approval workflowsQueues, thresholds and routing. | — | Included | Included | Included |
| SSO and RBACEnterprise identity and role scoping. | — | — | Included | Included |
| Advanced controlsRedaction rules, retention policy, export. | — | — | Included | Included |
| Private deploymentControl plane in your own cloud account. | — | — | — | Included |
| SupportResponse commitments. | Community | Standard | Priority | Dedicated |
| Request access | Talk to sales | Talk to sales | Talk to sales |
Swipe → to compare tiers
20FAQ
Questions engineers ask.
Where a capability is designed rather than built, the answer says so.
Product
Lattice is a control plane for production AI. It sits between your AI agents and the systems they act upon, and it gives engineering and security teams one place to see what agents did, define what they are allowed to do, approve the consequential actions and reconstruct any of it afterwards.
It is infrastructure rather than an application: it does not generate the action, it governs it.
Integration
Control
Data and deployment
Commercial
Put a control layer around your AI systems.
Connect your agents, understand their behaviour, define their boundaries and operate AI systems with a clear audit trail.