Skip to main content
Unlisted page
This page is unlisted. Search engines will not index it, and only users having a direct link can access it.

Modern Agent Anatomy

· 2 min read
Clifford
Clifford
info

This is the third of three articles on terminology with agents.

  1. Agent is a Terribly Non-Specific Term
  2. The "Hello World" of Agent Development
  3. Modern Agent Anatomy (this article)

Before naming the parts, I like to think about what boxes I would put on the whiteboard. If I wanted to just point at what I'm talking about, where does it sit in space? Relative to the other pieces of the agent stack: all the pieces for an LLM to be used as an agent.

The Agent StackThe application-owned interface, context, harness, and tools sit above a provider-owned API and hyperscaler infrastructure. The read-eval-tool loop sits inside the harness.The Agent StackInterface[ editor · TUI · web chat · native app · slack bot · chat integrations ]Context[ system prompt · filesystem ]./AGENTS.md./CLAUDE.md./.agents/skills/├── pdf-export/└── code-review/./src/*.rs./docs/*.mdHarness[ code · config ]Claude Agent SDKCodex App ServerPi Agent CoreNori HarnessRETLTools[ side effects ]grepbasheditwebfetchMCPyours to shapeAPI[ auth · billing · rate limiting ]Hyperscaler[ AWS · GCP · Azure ]Caching Service[ prompt-prefix reuse ]Inference ServiceGPUs[ kernels · KV cache · batching · tensor parallelism ]Model Weights[ “the model” ]the provider’s
The parts of a modern agent, separated into the application layer you shape and the model provider layer below the API boundary.

One turn, in motion​

The stack is useful for naming static boundaries. A prompt turn is easier to understand when those boundaries move: the harness assembles context, asks the model what to do, executes any requested tools, reduces their results into the next context, and repeats until the model returns a final response instead of another tool call.

The following diagram holds one example turn constant: change one line in a crate README. The harness loads its initial context, calls grep, calls edit, then returns a final response. The stack view shows ownership, the sequence view shows component messages, and the ledger shows the context accumulated for each later evaluation. A shared phase rail keeps all three views synchronized.

Prompt turn · synchronized plate

One prompt turn, three synchronized views

The same request moves through stack ownership, message sequence, and accumulated context. The shared phase rail keeps all three readings aligned.

01 · stack

Stack traversal

The harness coordinates every round trip between interface, context, model API, and tools.

02 · messages

Message sequence

The model is evaluated three times around two tool calls and their results.

03 · context

Context ledger

Seven typed history entries accumulate into the context used by later evaluations.

  1. Interface → Harness: prompt
  2. Harness → Context: load repo context
  3. Context → Harness: context loaded
  4. Harness → Model API: evaluate 1
  5. Model API → Harness: tool: grep README
  6. Harness → Tools: grep README
  7. Tools → Context: read README
  8. Context → Tools: README contents
  9. Tools → Harness: grep result
  10. Harness → Model API: evaluate 2
  11. Model API → Harness: tool: edit README
  12. Harness → Tools: edit README
  13. Tools → Context: write one line
  14. Context → Tools: edit applied
  15. Tools → Harness: edit result
  16. Harness → Model API: evaluate 3
  17. Model API → Harness: final response
  18. Harness → Interface: return response
shared phase01 / 08

Notes that are critical to elucidate the agent stack:

  • the three tiers of the harness (RETL, orchestrator, user customizations)
    • the RETL itself (the following or preceeding blog post)
    • orchestrator around the RETL (goal commands, multi agents, approval modes, etc)
    • Martin Fowler, the "inner harness"
    • then the "outer harness" from user (scripts used for hooks, custom tool definitions, skills, repo context)
  • how "harness engineering" blog post coined that term for specifically the outer loop
  • where do multi agent orchestrators fit? where do cloud runtimes fit?