Every serious technology organization, across industries and not just financial services, is running some version of the same experiment right now: how do you move from experimenting with LLMs to actually running autonomous, self-directed workflows in production. The use cases span a wide range. SDLC automation that writes, tests, and ships code with minimal human hand-holding. Legacy migration tools that read a codebase and re-platform it. Fraud detection pipelines that reason over transaction patterns in real time. Risk systems that need to explain their own decisions. Enterprise technology teams everywhere are treating this as an active engineering problem, not a theoretical one.
What’s changed is the tooling available to build these systems. A modern agentic stack typically brings together a few distinct kinds of building blocks. Orchestration frameworks like LangGraph manage state, sequencing, and control flow across a workflow. A harness, the layer that assembles a request and hands it to a model, sits underneath that. And increasingly, specialized coding agents like Claude Code operate inside that stack as an autonomous execution unit, one that can read a codebase, make changes, run tests, and iterate largely on its own. Layer in the Model Context Protocol (MCP) as the connective tissue between agents and external tools or data sources, and you get the rough shape of where agentic architecture is heading: a distributed system, not a single model call.
Worth being precise on one point here: A harness isn’t one specific product. It’s any layer that assembles a request, prompt, context, tool list, and sends it to a model. That can be a general-purpose Python script you write yourself, a framework like LangChain, or Claude Code’s own harness, which we’ll unpack below. They’re different implementations of the same job, not competing categories.
That combination, LangGraph for orchestration, a harness layer such as LangChain for wiring things up to models and tools, Claude Code for autonomous execution, and MCP connecting it all to the outside world, is genuinely the more interesting architecture to unpack, and it’s where this series is heading.
But before combining pieces, it’s worth understanding one of them properly on its own. This post zooms into Claude Code’s architecture. Consider it the foundation the next post builds on.
What Claude Code Brings to the Table
Claude Code is an autonomous engineering agent, not just a coding assistant in the narrow sense. Writing code is one part of what it does. It can also review pull requests, run and interpret test results, play an active role inside a CI/CD pipeline, and take other actions across a development workflow largely on its own. That range is what makes it a meaningful building block inside a larger agentic system, rather than just a chat interface for code.
At its core, this range comes from a specific internal architecture. Here’s what it looks like.
The Architecture: Three Concentric Layers
Strip away the tooling and Claude Code’s core request cycle comes down to three nested layers, each doing one job.
The outermost layer is Claude Code itself, the harness. This is the part that assembles the actual request: it takes your prompt, pulls in the relevant conversation history, the system instructions, and the list of tools and skills available, and packages all of it into a single structured request. This is also the layer with all the practical engineering built in, file system access, running tests, git operations, multi-file editing, so that by the time a request leaves this layer, it’s not just “here’s a prompt,” it’s “here’s a prompt plus everything needed to act on the result.”
The middle layer is the API endpoint, the serving layer the request travels to. Its job is narrower than people assume: it takes the incoming text and tokenizes it, converting it into the integer IDs the underlying model actually operates on, then routes that request to the model. It’s the front door, not the model itself, a distinction worth being precise about since the same model can sit behind different API surfaces.
The innermost layer is the model, the weights and the architecture code. The weights are the actual learned parameters, stored as large tensors on disk and loaded into GPU memory. The architecture code is what drives computation through those weights, layer by layer, turning input tokens into an output. This is where the actual “thinking” happens; everything outside this layer exists to get a well-formed request in, and a usable response back out.
The reason this layered view matters isn’t academic. It tells you exactly what you’re extending when you build on top of Claude Code. Add a capability at the harness level, and the model and API underneath stay untouched. Swap the model behind the API, and the harness and its capabilities stay intact. Understanding where the boundaries sit is what makes it possible to reason clearly about combining Claude Code with other frameworks, which is exactly where this series goes next.
A Few of the Capabilities Built on This Architecture
That harness layer is where Claude Code’s day-to-day capabilities live. A handful worth knowing about: skills, reusable packaged instructions for a specific kind of task; CLAUDE.md, a project-level memory file that gives Claude Code standing context about a codebase without re-explaining it every session; hooks, points where you can inject your own validation logic or commands into its workflow; and headless mode, which lets it run non-interactively as a CI step or be invoked programmatically via SDK, rather than needing a human in a terminal.
That’s a small slice of a much larger feature set. This post isn’t meant to be a product walkthrough, the goal here is the architecture, not the catalog. For the full picture, Anthropic’s own documentation is the right place to look: code.claude.com/docs
Where This Is Going
Claude Code doesn’t have to run in isolation. In practice, it’s most powerful as one specialized node inside a larger, orchestrated system, one where a framework like LangGraph owns the business logic, sequencing, and approval gates, while Claude Code is invoked specifically to write, review, and verify code. That same distributed picture can extend further still: pulling in lighter, self-hosted open-weight models (via platforms like Ollama) for cost-sensitive sub-tasks, and using MCP as the standard way for all of these pieces to talk to external tools and data.
That’s the architecture worth unpacking next: how orchestration, a harness layer, Claude Code, and MCP come together as a distributed system capable of solving real problems across industries, from AI-driven SDLC automation to real-time fraud and risk analytics.
Stay tuned for Part 2.
Leave a Reply
You must be logged in to post a comment.