Skip to content
openagentix openagentix docs

The agentix pattern

Application architecture decides how code is structured. Agent architecture decides who may do what at run time, when a model chooses the next step. The two meet at the MCP server: an adapter in application terms, a capability boundary in agent terms. The agentix pattern is the shape open-agentix is built around for the second question.

Agent architecture and application architecture meet at the MCP serverUpper band: agent architecture, decided at run time; agents, one per step, call tools through a policy gate with audit. Lower band: application architecture, decided at design time; each system has its own layers. The MCP servers sit on the line between the bands: an adapter in application terms and a capability boundary in agent terms.agent architecture: who may do what, at run timecapabilities, blast radius, approvals, handovers, costagents, one per steppolicy gate + auditjira MCPcrm MCPMCP server: an adapter (app view)and a capability boundary (agent view)JiraAPI / portdomaindataCRMAPI / portdomaindataapplication architecture: how code is built, at design timelayers, services, data ownership, deploy units
Two orthogonal questions. They meet at the MCP server.

Definition

Section titled “Definition”

Every system an agent may touch sits behind exactly one MCP server, which owns its credentials and exposes its capabilities as typed tools, separated into read and write. Every business process is a versioned plan of steps; each step is executed by its own narrowly scoped agent that holds only the tools its step needs, hands over a typed artifact, and reaches any system only through a deterministic policy gate that records every decision under the run id.

Anti-pattern versus the agentix patternTop: one agent holding every tool talks to one do-everything MCP server that holds the credentials of ten applications. Bottom: the agentix pattern. Three agents, one per step (research reads, analysis has no tools, action writes one thing), reach systems only through a policy gate with audit, and each system sits behind its own MCP server; the Git server is not granted to any step.Anti-pattern: one god agent, one do-everything MCP serverone agent, every toolone MCP server, ten apps, every credentialapp 1app 2app 3app 4app 5app 6app 7app 8app 9app 10agentix pattern: one agent per step, one MCP server per systemresearchreads jira, crmanalysismodel onlyactionjira: issue.createpolicy gate (allow / deny / approval) + audit, run idjira MCPcrm MCPgit MCPnot granted
Top: one agent and one MCP server for everything. Bottom: the agentix pattern, one agent per step, one MCP server per system, a gate in between.

Rules

Section titled “Rules”
RuleIn one line
R1One MCP server per system or bounded context, the only door to it. Typed tools, read and write separate, credentials only there. Different risk classes: separate tool sets and policy per tool.
R2A process becomes 1..n agents, one per step by default. Split when risk, data class, privilege, model, failure handling, cost or approval differ; keep together when steps share context and privilege. No god agent.
R3Agents never reach systems directly: every tool call passes the policy gate and the audit trail.
R4Handovers are explicit, schema-typed and minimal, not shared memory or free chat between agents.
R5Orchestration is data: a versioned plan, not an all-knowing orchestrator agent.
R6Budgets, limits and identity per agent.
R7Everything is observable by run id and agent id.
Worked example: ticket triageAn event starts the research agent, which may only call read tools of the Jira and CRM MCP servers. It hands typed findings to the analysis agent, which has no tools. The analysis agent hands a typed decision to the action agent, which may call one write tool, issue.create on the Jira MCP server, and only after a human approval. Every call passes the policy gate and is audited.event: ticket.createdresearchreads onlyanalysismodel only, no toolsactionone write, after approvalfindings.jsondecision.jsonpolicy gate + auditjira MCP serverreadissue.getreadissue.searchwriteissue.createcrm MCP serverreadcustomer.getwritecustomer.updatehuman approval before the callevery call into an MCP server passes the gate and is audited under the run id
Reads and writes are separate tools. Only the action step may write, once, after approval.

Anti-patterns

Section titled “Anti-patterns”

God agent, one do-everything MCP server for many systems, one MCP server per endpoint, shared credentials, free chat between agents, an orchestrator agent that holds every tool, and policy written into the prompt.

Status in open-agentix

Section titled “Status in open-agentix”

Available in 0.1 Pipelines of 1..n agents in agents.md with per-agent tools, argument rules, approvals, model and budget; the deterministic policy gate; the hash-chained audit trail; steps and costs per run and agent.

Roadmap Schema validation of handovers (today the previous output is passed on as text, format: json is parsed but not validated), conditional plan steps, named read/write tool profiles per MCP server, per-run credentials and isolated workers (v0.2), and Agent Check / Agent Plan generation (advisory). See the roadmap.

References

Section titled “References”

Accessed 2026-10-04. The pattern is our own synthesis. It is consistent with these pages, which do not prescribe it: MCP servers “expose specific capabilities” and each tool “performs a single operation”; subagents get “specific tool access” through a tools allowlist. Typed handovers (R4) and plans instead of an orchestrating agent (R5) go further than these sources.

The reasoning, a worked example and the trade-offs are in the blog post Agent architecture is not application architecture.