Claw Code harness architecture diagram showing the user loop, Python orchestration layer, Rust runtime, and external systems such as the LLM provider, file system, and MCP server.
User { # User
n1: circle label:"Start"
n2: rectangle label:"Enter CLI command"
n3: rectangle label:"View streamed output"
n4: circle label:"Done"
n1.handle(right) -> n2.handle(left)
n2.handle(bottom) -> Python.n5.handle(top) [label="Command"]
n3.handle(right) -> n4.handle(left)
}
Python { # Python Orchestration
n5: rectangle label:"Load session context"
n6: rectangle label:"Build prompt"
n7: rectangle label:"Call model"
n8: diamond label:"Tool needed?"
n9: rectangle label:"Route tool call"
n10: rectangle label:"Update memory"
n11: rectangle label:"Finalize response"
n5.handle(right) -> n6.handle(left)
n6.handle(right) -> n7.handle(left)
n7.handle(bottom) -> External.n15.handle(top) [label="LLM request"]
n8.handle(bottom) -> n9.handle(top) [label="Yes"]
n8.handle(right) -> n11.handle(left) [label="No"]
n9.handle(bottom) -> Rust.n12.handle(top) [label="Tool call"]
n10.handle(right) -> n11.handle(left)
n11.handle(top) -> User.n3.handle(bottom) [label="Answer"]
}
Rust { # Rust Runtime
n12: diamond label:"Permission granted?"
n13: rectangle label:"Execute tool in sandbox"
n14: rectangle label:"Stream tool events"
n12.handle(right) -> n13.handle(left) [label="Yes"]
n12.handle(top) -> Python.n11.handle(bottom) [label="Denied"]
n13.handle(bottom) -> External.n16.handle(top) [label="File access"]
n13.handle(right) -> n14.handle(left)
n13.handle(top) -> External.n17.handle(bottom) [label="MCP call"]
n14.handle(top) -> Python.n10.handle(bottom) [label="Observations"]
n14.handle(left) -> User.n3.handle(right) [label="Stream"]
}
External { # External Systems
n15: rectangle label:"LLM provider"
n16: rectangle label:"File system"
n17: rectangle label:"MCP server"
n15.handle(left) -> Python.n8.handle(right) [label="Plan"]
n16.handle(left) -> Rust.n14.handle(right) [label="File data"]
n17.handle(left) -> Rust.n14.handle(bottom) [label="Tool data"]
}
A single-agent AI architecture where one agent handles everything: parsing requests, reasoning, calling tools via MCP, and generating responses. This is the default architecture for prototypes and simple automations—easy to debug but hits context-window limits quickly and is hard to parallelize. Ideal for MVPs and solo builders shipping fast.
The simplest AI-native architecture — a single agent that receives user input, reasons, plans, decides on tool calls, processes results, and generates responses. Direct MCP connection over stdio or HTTP. Best for MVPs and when low latency matters.
Zero-trust AI agent identity architecture with JWT validation, scoped OBO token exchange, SPIFFE/SVID workload identity, and MCP tool authorization.
MCP security gateway architecture that authenticates tool calls, routes execution into isolated sandboxes, sanitizes responses, and returns clean results to the AI agent.
A microservices API gateway architecture diagram showing request routing, JWT authentication, rate limiting, service discovery, and response aggregation across distributed backend services. This template models the entry point for all client traffic in a microservices ecosystem, enforcing security policies before requests reach internal services. Ideal for platform engineers designing scalable API infrastructure with centralized cross-cutting concerns.
A service mesh architecture diagram with Istio or Linkerd sidecar proxies handling mTLS encryption, traffic policies, circuit breaking, and distributed tracing across microservices. This template visualizes how a service mesh abstracts networking concerns away from application code, enabling zero-trust communication between services. Essential for teams adopting service mesh infrastructure to improve observability and security.