# Anatomy of an Agent Harness > Shared edition: local file paths were removed and concept-study links were reconnected to the public conversation artifacts. The working content is otherwise preserved. ## Consolidated master plan for the founder-forum presentation **Status:** Twenty-seven-slide production deck built; final causal, narrative, visual, and file QA in progress **Format:** 27 slides, 16:9, speaker-led **Duration:** 40 minutes **Audience:** Technically literate technology founders who use modern AI products but may not have built or operated a production agent harness **Purpose of this document:** This is the durable source of truth for research, visual development, slide production, speaker notes, rehearsal, and later revisions. This document consolidates three successive presentation plans. The detailed 23-slide interview plan is the primary source. The earlier production specification contributes important architecture, evidence, safety, visual, and acceptance-test detail. The original outline contributes only a few durable framing and deliverable decisions. Where those plans disagree, the most recent user decisions govern. --- ## 1. Communication job This is a technical map, not a founder checklist, a vendor comparison, a Mastra tutorial, or a pitch for CEP. Its job is to replace the audience’s vague idea that an agent is “a smart model with some tools” with a precise mental model of the software surrounding the model. The presentation begins with the model because the audience needs to remember where the underlying capability comes from. It then makes a clean distinction between a base model, an assistant, a tool-using assistant, an agent-capable model, an agent loop, and a production harness. The body of the talk follows a user message through that harness and opens each important component. The final sections explain why one apparent agent may contain many different models, how those models should be selected using task-specific evidence, and how production feedback becomes an improvement loop. By the end, a technically informed founder should be able to explain: - why post-training changes a base model into an assistant and then an agent-capable model; - the small model–tool–observation loop at the center of an agent; - the major responsibilities a production harness adds around that loop; - why guardrails, memory, retrieval, verification, and subagents may each use different models; - how public benchmarks, private evals, cost, latency, and taste combine into a model decision; - how good and bad production outcomes become regression cases and, eventually, possible fine-tuning data; - how the same anatomy appears inside Codex and Claude Code; - how better prompting often means giving the harness better context, tools, constraints, and proof of completion. The central movement is: > We trained a model that can deliberate and act. Now let’s biopsy the machinery that makes that capability useful, economical, controllable, and improvable. “The harness may be the product” or “the harness may become the moat” can emerge as an earned implication. It should not be imposed as a thesis that every slide must prove. --- ## 2. Narrative principles The story follows one transformation. A raw predictive model becomes an assistant, then a tool user, then an agent-capable model. The harness encloses that capable but imperfect core and makes its behavior dependable enough to use. Once the anatomy is visible, the talk shows how the harness can measure itself, substitute models, learn from taste, and improve. The deck should be cumulative. Slides 1–2 establish the promise and the three-act route. Slides 3–8 evolve one persistent model artifact and end by enclosing it in a harness. Slides 9–18 open that harness and follow one request through its major responsibilities. Slides 19–24 reveal the portfolio of models and the evidence-driven improvement system. Slides 25–27 map the anatomy into real coding agents, prove the deck was made through the same loop, and close with a portable diagnostic. Each slide needs one primary claim and one primary piece of evidence. A slide may contain several supporting ideas, but the speaker must be able to state its one-sentence job. Security should not become a detached fear section. Each new capability creates a corresponding control problem: retrieval needs grounding, actions need authorization, memory needs privacy boundaries, subagents need scoped context and budgets, and long-running loops need stop conditions and verification. The examples should escalate in complexity while preserving the same basic mental model. A calculator or search tool is obviously a function. RAG is a function containing a search subsystem. A skill is a function that loads instructions. A subagent is a function whose implementation happens to run another agent. This escalation is central to demystifying the harness. CEP is supporting evidence, not the narrative protagonist. The CEP Dreamer eval is valuable because it is real and surprising. Selected dealership examples can make tools, permissions, and outcomes tangible, but the talk must not become an architecture review or a company pitch. Codex is the main practical biopsy near the end because it is familiar, current, and directly connected to how the presentation is being produced. --- ## 3. Harness topology and audience-facing anatomy The topology below remains the technical source of truth, but the presentation should not force all of it into one hero image. The audience-facing constitutional visual is the familiar rolling agent wheel. The biopsy pauses that wheel and separates its few important components along one axle. This gives the audience a simple table of contents for the slides that follow. A separate schematic may still be useful for explaining execution order or asynchronous work, but it must support the exploded wheel rather than replace it with a dense network. At the outer level, the synchronous request lifecycle is: > user or channel → identity/thread normalization → input controls → context assembly → agent loop → response and output controls → user The inner agent loop is: > assemble the current working context → call the actor model → either produce a response or request a tool → validate and execute the tool → append the observation → continue until a verified stopping condition Instructions, skills, recent conversation, memory, retrieved evidence, task state, and tool schemas feed context assembly. They are not necessarily sequential processors through which every message passes. Tools and subagents branch conditionally from the inner loop. Permissions, approvals, budgets, retries, timeouts, idempotency, and side-effect policies surround execution. Verification controls whether the trajectory exits or loops again. Beneath the live request path is an asynchronous learning plane: > traces and outcomes → human or automated feedback → curated cases → versioned evals → prompt/tool/workflow/model experiments → deployment decision Memory observation, broad scoring, dataset construction, and expensive judges may also run asynchronously. Any supporting schematic must visibly distinguish the latency-sensitive path from work that can happen later. Every detailed anatomy slide can retain a small ghosted view of the exploded wheel with the relevant component highlighted. Guardrails return to the outer shell and gate. System prompts and skills return to the instruction cartridge. Tools, RAG, and subagents return to the interface ring. Memory returns to the spool. Verification can return to the gate or rail exit. The rest of each slide uses the clearest real artifact for that component: a prompt, schema, execution trace, transcript, screenshot, chart, or code excerpt. --- ## 4. Timing architecture The production deck contains 27 slides, including the title, agenda, two section transitions that also perform narrative work, and the closing diagnostic. The current pacing target totals approximately 40 minutes: | Slides | Narrative act | Target | | ------ | ------------------------------------------------------ | -----------: | | 1–2 | Promise and route | 2.5 minutes | | 3–8 | From base model to production-agent problem | 8 minutes | | 9–18 | Biopsy, inner loop, and harness dissection | 15.5 minutes | | 19–24 | Model portfolio, evals, replay, and selective training | 9.5 minutes | | 25–27 | Coding-agent anatomy, making-of proof, and close | 4.5 minutes | The opening recap and the master-map explanation are protected. If rehearsal runs long, shorten supporting examples in the model-selection and closing sections before rushing the core anatomy. --- ## 5. Slide-by-slide narrative specification The 23 entries below are the durable narrative units from which the 27-slide production deck was composed. The production deck adds the title, agenda, a dedicated Part I transition, and a final three-question close; its Part II and Part III transitions also perform narrative jobs rather than behaving as empty dividers. ### Slide 1 — Before an agent, there is a model **Job:** Reactivate the audience’s earlier understanding of next-token prediction and establish the raw material that every later stage will modify. Pretraining converts an enormous volume of human-produced tokens into a predictive model that is exceptionally good at estimating what comes next. “Compressing the internet into a model” is a useful spoken metaphor, provided the talk immediately clarifies that the model did not store a literal database copy of the internet. It learned statistical structure, patterns, relationships, and representations that allow it to continue text and generalize. The emotional sequence should be recognition, correction, and awe. The audience first recognizes the autocomplete explanation from the earlier talk. It then receives the more precise account. Finally, it is invited to notice how remarkable it is that this training objective produces broad competence at all. The recurring model artifact begins as a coarse, angular, premium black object—possibly a tetrahedron or similarly low-faced polyhedron. The exact geometry is not locked. It must feel powerful, dense, and unfinished rather than cute or decorative. The object will persist through the opening sequence, allowing each additional capability to feel like another refinement of the same underlying intelligence. ### Slide 2 — The model becomes an assistant **Job:** Explain how post-training creates a conversational participant without implying that role tokens alone create helpfulness. The raw model still predicts tokens, but post-training changes the behavior it is likely to produce. Role and turn delimiters tell it which participant is speaking and what kind of continuation is expected. Supervised demonstrations, preference optimization, and reinforcement learning teach it what useful, safe, instruction-following assistant behavior looks like. The intellectual center combines two ideas: post-training installs a conversational protocol, and behavioral alignment makes that protocol useful. The slide should explicitly preserve the fact that the underlying mechanism remains token prediction. The evolving object gains fitted charcoal facet plates and a more refined geometry while its raw material remains visible. Glass is deliberately withheld because the later transparent wheel means harness, not post-training. Beside the object, the audience sees a real, legible public OpenAI Harmony-format example with the relevant roles or channels annotated. The literal artifact proves the implementation detail; the model object carries the larger refinement metaphor. The talk must distinguish public protocol structure from hidden reasoning. It should not reproduce private prompts or imply that internal chain-of-thought is available to application developers. ### Slide 3 — The assistant learns to use tools **Job:** Show why tool use emerged and establish the request–execution boundary. Early tools addressed concrete weaknesses. A calculator supplied reliable arithmetic. Search supplied current information beyond the training cutoff. Code execution allowed the system to inspect, transform, test, and create things on a real computer. Models had to be post-trained to emit structured tool requests and interpret returned observations—effectively receiving additional “keys on their keyboard.” The model does not directly browse the internet, query a database, or execute code. It produces a request. A visibly separate harness boundary validates and authorizes that request before an ordinary executor performs the action; the observation returns through the same boundary as another message. The following agentic slide reuses this exact interface so persistence reads as repeated messages, not a new magical mechanism. A real annotated trace should show the user request, structured tool call, external execution, observation, and final response. The persistent object becomes a higher-sided black polyhedron. Each new trained capability removes some of the roughness and makes the model more able to move through the world. This visual evolution must be substantially more meaningful than changing glow color or adding another dotted path. ### Slide 4 — A tool user becomes an agent-capable model **Job:** Explain the leap from one-shot tool use to persistent multi-step work. The transition combines three ideas. Long-horizon reinforcement learning rewards successful trajectories rather than isolated responses. The model learns to inspect results, recognize mistakes, backtrack, change strategies, and continue. That training makes additional test-time computation productive: when allowed more time to deliberate or explore, the trained model can improve its chance of success. The primary conceptual shift is from producing a plausible answer to pursuing a verified outcome. The model has developed persistence and recovery behavior, and its training has rewarded complete trajectories. These are three views of the same transition rather than three competing definitions. The slide should combine a compact real trajectory—plan, tool call, failure, revision, second action, verification—with a small test-time-compute curve. The object becomes nearly rollable but remains visibly faceted. It stays fixed while requests and observations cross the same separate tool boundary introduced on the previous slide. Wording must distinguish training from inference. The deployed model is not normally updating its weights while it thinks. Its inference may resemble search and self-correction because reinforcement learning taught it productive reasoning strategies. OpenAI’s o1 explanation is the current factual anchor: [Learning to reason with LLMs](https://openai.com/index/learning-to-reason-with-llms/). ### Slide 5 — A capable model is not yet a production agent **Job:** Make the harness feel inevitable. Capability does not equal reliability. An agent-capable model can do impressive work under favorable conditions, but one invocation is constrained by its finite context, available interfaces, and the trajectory it can sustain. It has no durable application state, memory policy, authorization system, execution environment, observability, or dependable runtime of its own. The harness repeatedly creates the conditions in which the model can succeed. It assembles the right context, preserves continuity, exposes and governs tools, controls the loop, observes outcomes, and helps the model recover. The visual boundary must remain honest. The still-faceted model core is enclosed inside a perfectly engineered transparent sphere. The harness does not magically alter the model’s weights. It smooths its motion, supplies continuity, and keeps capable behavior pointed toward a goal. This is the hinge into the body of the talk: > To build an agent—or to use one well—we need to understand the anatomy of the harness around the model. ### Slide 6 — Biopsy of an agent harness **Job:** Turn the familiar rolling agent into a simple visual table of contents for the anatomy section. The wheel from Slide 5 pauses on its rail and separates laterally along its axle like a precision bearing assembly. The audience sees only the components that will matter over the next several slides: the faceted model core, an outer guardrail shell and gate, a compact system-prompt cartridge, a standardized tool-interface ring, and a layered memory spool. The image should not attempt to show the complete request lifecycle, every conditional branch, or the asynchronous learning plane. Its purpose is recognition and orientation: this apparently simple rolling object contains separable responsibilities that can be inspected one at a time. Later anatomy slides reuse a small ghosted version of the assembly and highlight the relevant component. Skills can be revealed as procedural material loaded through the instruction cartridge. RAG and subagents can be revealed as more sophisticated capabilities behind the tool-interface ring. Verification can return to the gate or rail exit. Real prompts, schemas, traces, screenshots, and transcripts provide the detailed proof beside that orientation image. The approved concept is [the exploded agent-wheel biopsy](/thread-artifacts/21-generated-01.jpg). The earlier network-first prototype was rejected because it attempted to make the biopsy and complete topology diagram perform the same job. ### Slide 7 — The surprisingly small loop at the center **Job:** Reduce the perceived magic to a comprehensible control loop. At its simplest, the harness is a while-loop wrapped around an extended conversation: assemble context, call the model, execute requested tools, append observations, and call the model again until a verified stopping condition or operational limit is reached. A tiny real code example should be the primary explanation. It can be paired with a physical loop mechanism if that increases clarity. The trace should make it obvious that tools are additional messages in the conversation. Verification controls the exit. When verification fails, the harness returns actionable evidence to the trajectory. Compaction allows work to continue when the original context becomes too large. Budgets, maximum turns, approvals, retries, and escalation prevent persistence from becoming uncontrolled expenditure or unsafe action. The Ralph loop should not take over this slide. It can appear as a recognizable contemporary label for persistent looping. Modern agentic models increasingly exhibit persistence in their trained behavior; the harness provides continuation, compaction, verification, and boundaries. The practical relationship can be revisited in the Codex anatomy. ### Slide 8 — Guard the expensive loop before it starts **Job:** Present guardrails as a commercial, security, and product necessity. An early processor can inspect a small amount of recent input and decide whether the request is in scope, abusive, adversarial, or obviously wasteful. It should be fast and inexpensive because it sits in the latency-sensitive path and may process hostile traffic. Deterministic rate limits and input normalization belong beside model-based topicality, moderation, or risk classification. The commercial risk is cheap malicious input triggering expensive long-running trajectories. The product risk is a specialized assistant being used as an unrelated general service. The security risk is prompt injection against an agent with access to messages, customer data, email, files, or consequential tools. A small guard model is not a complete security boundary. Prompts guide behavior; permissions, tenant isolation, tool restrictions, data separation, and approval gates provide stronger enforcement. The master map highlights the input-control stop. The detail view should use real implementation evidence: an abbreviated classifier contract, latency and cost targets, and a verified public abuse example. Chipotle may be included if the exact incident is sourceable. Home Depot must be omitted unless equivalent evidence is found. OpenClaw or email-injection scenarios should be framed as threat models unless supported by a concrete source. ### Slide 9 — The conversation starts with a secret message **Job:** Reveal the hidden instruction stack and reframe “prompt engineering” as context engineering. Before the user writes anything, the model may receive provider policy, developer instructions, tool definitions, project guidance, activated skills, conversation history, memory, and runtime state. The model has been trained to treat these sources differently from an ordinary user message. The primary visual should be a real request or public prompt structure broken into literal blocks. The audience should see the invisible pieces being assembled and understand their authority, token cost, stability, and cache implications. Tool names, descriptions, and schemas belong here because exposing a tool also changes the prompt. Codex provides the most useful real anatomy. Claude Code can provide a token-cost comparison if the number can be established from public or directly observable behavior. Provider-specific serialization must not be presented as a universal standard. The slide should distinguish instructions from enforcement. A developer message can strongly guide behavior, but permissions and executable policies are required when behavior must be guaranteed. Preserving a stable instruction prefix may also improve prompt-cache economics. ### Slide 10 — A tool is a prompt plus an executor **Job:** Open one simple tool and show every responsibility. The model sees a tool name, description, arguments, usage guidance, and possibly an expected result shape. Those are instructions and therefore part of the prompt. The harness validates the requested arguments, checks authorization, executes ordinary software, handles errors, and returns an observation. The result does not need to be JSON. It can be Markdown, plain text, an image, structured data, stdout, or an error. The quality of the tool contract often matters as much as model intelligence. Names, descriptions, schemas, examples, and error behavior determine whether the actor can use it reliably. The harness owns authorization, idempotency, retries, timeouts, side-effect policy, and approvals. The model proposes an action; the harness decides what can actually happen. Use a calculator or web-search tool because the entire contract can be understood immediately. Show the real schema-to-execution trace. A premium rendered object is optional and should be discarded if it competes with the contract. ### Slide 11 — A skill is a prompt loaded on demand **Job:** Demystify skills and explain progressive disclosure. A skill is reusable procedural knowledge loaded into context when relevant. Instead of forcing every specialized workflow into every request, the agent sees a catalog, selects a skill, and receives a Markdown instruction package. That package may point to scripts, templates, assets, references, or additional conventions. In Codex-like implementations, skill loading behaves like a tool call whose output is further instructions. The memorable definition is “a prompt loaded on demand.” The broader interpretation is procedural memory: stored know-how for completing a recurring class of work. The primary visual compares context immediately before and after loading a real presentation skill. It should show exactly which instructions appeared and why the context cost was incurred only at that moment. This plants the making-of story early without prematurely claiming success. ### Slide 12 — Observational memory is the long-horizon leap **Job:** Explain that memory is context management over time and show why observational memory changes the economics. The talk should briefly distinguish recent thread history, compaction summaries, working memory containing current state, durable Markdown or profile memory, semantic recall, and observational memory. These are different mechanisms with different jobs, not interchangeable implementations of one magical feature. The main story is observational memory. A moving context window travels through a long conversation while an asynchronous observer extracts durable, recallable observations. Lower-value detail can be consolidated while an append-stable prompt prefix improves the chance of provider cache hits. Observation and reflection can happen outside the critical response path. A controlled transcript should compare naive repeated compaction with observational memory and ask both systems to recall an old consequential fact. The memory model needs sufficient context, excellent compression, temporal fidelity, speed, and low cost; it does not necessarily need frontier-level reasoning. Mastra’s published observational-memory work is the leading concrete example and should be attributed to Mastra rather than generalized to the entire industry: [Mastra observational memory research](https://mastra.ai/research/observational-memory). Do not claim that it automatically makes every turn 90% cheaper. Total savings depend on provider cache pricing, cache-hit rate, uncached input, output, and observation frequency. ### Slide 13 — RAG is a search tool containing a subsystem **Job:** Show how an agent acquires private or current evidence and reinforce that one agent may contain several models. When required knowledge lives in a company database or elsewhere on the internet, the agent calls a search tool. Inside that function, query generation, keyword search, embeddings, vector similarity, filters, candidate retrieval, reranking, and evidence packaging may all participate. A hybrid architecture keeps retrieval and ranking dependable while allowing the actor model to decide whether the evidence is sufficient or another search is needed. The embedding model, reranker, query model, and actor model each perform a different job. The visual should use real document cards. Approximately thirty candidates enter; scores and filters reduce them to three passages that enter context. One plausible but irrelevant result should remain visible to demonstrate the reranker’s contribution. The final answer cites the admitted evidence. Improvement comes from retrieval, ranking, groundedness, and citation evals—not merely swapping the final conversational model. ### Slide 14 — A subagent is another tool call **Job:** Make delegation feel powerful without making it mystical. A subagent is a function that accepts a large task packet, runs another agent loop, and returns an output to the parent. Context isolation, parallel throughput, and specialized intelligence are valuable consequences of that definition. Each worker can receive narrow instructions, its own context, a different model, scoped tools, permissions, and a budget. It absorbs noisy exploration and returns a concise result so the parent does not carry every intermediate detail. The concrete example should be image generation or codebase research. In the image example, the parent agent writes a specialized prompt and calls an image-generation agent or model. In the research example, a child explores the repository and returns findings. Include a compact distinction between workflows and subagents. A deterministic workflow is preferable when a sequence must be repeatable, auditable, and structurally constrained. A subagent is useful when the work benefits from judgment, exploration, isolation, or parallelism. More agents are not automatically better; delegation adds cost, coordination overhead, and new failure boundaries. ### Slide 15 — The final answer must be verifiably true **Job:** Establish verifiability as the exit condition for dependable automation. The actor’s confident statement that work is complete is not proof. The harness should use the strongest evidence the task allows. Deterministic checks include compilation, tests, schema validation, file existence, database state, sent messages, and resolved citations. Independent evaluator models can judge work that lacks a mechanical oracle. Human review or downstream product outcomes are required where quality remains subjective. The visual returns to the loop from Slide 7 and reveals the verifier-controlled exit gate. A coding task makes the idea concrete: the agent says it finished, but compilation, tests, screenshot verification, and review determine whether the loop exits. This explains why coding and mathematics are unusually productive agent domains: many outcomes are verifiable. Open-ended tasks often require rubrics, pairwise comparison or Elo-style ranking, proxy metrics, and downstream success criteria. The practical prompting lesson is to tell the agent how it can know the work is done. The analogy is a 90-day success definition for a new hire: convert taste into observable evidence wherever possible. Response validation, redaction, citation handling, channel adaptation, and final policy checks also sit near this exit. The completed trace records the calls, tool decisions, latency, cost, verification evidence, and outcome for later use. ### Slide 16 — Matching the model to the job is harness work **Job:** Reveal the hidden portfolio of models inside one apparent agent. The actor model plans and acts, but a fast classifier may guard input, a long-context model may observe memory, an embedding model retrieves candidates, a reranker selects evidence, a smaller judge verifies completion, and a specialized generator creates images. Each role has different requirements for intelligence, context, throughput, latency, modality, and price. The master map returns with concrete model-role badges at the relevant stops. This should feel like a reveal of the whole system rather than a new metaphor. The operating principle is to be fiercely disloyal to the model. Matching models to jobs is a harness responsibility, and the system should allow substitutions when measured evidence changes. A gateway provides unified access, accounting, routing, fallbacks, and provider flexibility. It does not determine correctness; the application’s evals and outcomes do. Static role assignments are a sensible starting point. Dynamic routing and elaborate fallback should be introduced only when product evidence justifies their complexity. ### Slide 17 — Public benchmarks scout; they do not select **Job:** Explain how to create a credible shortlist without evaluating every available model. The CEP Dreamer agent is the worked example. The process begins by writing the job specification and constraints. The Dreamer needs sufficient knowledge, low hallucination, acceptable speed, and acceptable cost. An Artificial Analysis measure believed to be the Omniscience Index helped identify models that know broadly while admitting uncertainty instead of confidently inventing. A current screenshot of that benchmark sits on a separate analytical screen while a physical scouting instrument makes the reduction visible: a dense public intake field passes through five job-constraint channels and ends in three to five empty test cradles. The cradles remain empty because public data can reduce a huge market to plausible candidates, but it cannot determine which candidate performs the private job correctly. That decision machinery appears only on the following private-eval slide. The exact index name, date, scores, and shortlisted models must be verified. The screenshot should be presented as a historical input to one decision, not a timeless model ranking. ### Slide 18 — An eval is an executable job description **Job:** Show how the shortlist is tested against the real work. The Dreamer evaluation combines representative CEP cases with difficult edge cases that reveal hallucination, shallow compliance, or failure to follow the intended behavior. Every candidate receives identical inputs and controlled settings. An explicit rubric gives a model judge repeatable criteria. Blinded human review calibrates that judge and detects systematic judging errors. Failure categories remain visible rather than disappearing into one average score. Cost and latency are recorded beside quality. The slide should put one hard case under the microscope. Several anonymized candidate outputs appear beside the rubric, allowing the room to see why outputs with superficially similar prose receive different scores. The broader evaluation matrix exists behind this example but should not dominate the slide. This slide should make the phrase “an eval is an executable job description” feel literal: it is the specification against which a new model, prompt, tool, memory system, or harness change can be repeatedly tested. ### Slide 19 — The chart exposes tradeoffs; taste makes the decision **Job:** Explain model selection without pretending that a benchmark chooses the business strategy. The production deck currently uses the authentic Artificial Analysis Intelligence Index versus cost-per-task scatter as a public example of price-performance geometry. It is labeled as a scouting view, not as the Dreamer result. The slide states the boundary explicitly: the shape is public, but the product’s frontier must come from its own cases. When sanitized private data is available, replace the public screen with Dreamer quality against cost, encode latency as bubble size, draw the Pareto frontier, and label the real candidates. A model is dominated when another candidate is at least as good across the relevant dimensions and strictly better on one. The frontier narrows the decision; it does not make it. Sometimes latency is the product. Sometimes accuracy matters far more than speed. Sometimes cost determines viability, and sometimes it is irrelevant compared with the value of a correct outcome. The slide should annotate why the chosen model matched the priorities at that moment and which compromise was consciously accepted. Taste enters here as informed product judgment rather than unmeasured preference. The model field should periodically rerun the same versioned tournament. The harness remains loyal to measured outcomes, not the incumbent model. ### Slide 20 — Capture taste before attempting to train it **Job:** Turn good and bad experiences into reusable learning evidence. The product’s inspect screen—with thumbs-up, thumbs-down, and a reason—provides the real anchor. The essential dataset begins with examples of “this was good,” “this was bad,” and “here is why.” Explicit feedback is supplemented with observed behavior such as acceptance, edits, retries, reversals, human takeovers, completed workflows, and downstream outcomes. Automated judges add another signal. The underlying trace should preserve enough configuration to replay the case: instructions or prompt version, model, relevant tool calls, observations, timing, cost, verification evidence, and outcome. Collection must respect consent, privacy, redaction, retention, and tenant boundaries. The first use of the data is replay, not fine-tuning. Run a changed prompt, tool, workflow, memory system, harness implementation, or model against the same cases and judge whether behavior improved. A production failure should first be assigned to the layer that owns it. Prompt changes cannot repair broken data or a defective tool, and a larger actor model may not repair poor retrieval. ### Slide 21 — Fine-tuning is the last mile **Job:** Explain when training becomes justified without turning the talk into a fine-tuning tutorial. Fine-tuning becomes attractive when the desired behavior can be demonstrated, the remaining accuracy gap is measurable, prompting and harness improvements have been exhausted, and the required knowledge or behavior exists primarily in proprietary data. It may also be justified when an expensive model already performs the job and the business needs to reproduce that behavior with a smaller, faster, cheaper model. The treatment should remain conceptual. Corrected demonstrations can support supervised fine-tuning. Good/bad pairs may support preference optimization. Verifiable outcomes may support reinforcement-style training. Ordinary production traces are not automatically training-ready. The worked example should be distillation of expensive accepted behavior into a smaller model. The reported Cursor/Kimi example may be used only after verifying the exact model, data, method, and public statement. If the claim cannot be verified, replace it with a documented example or explain the pattern generically. Fine-tuning is an experiment evaluated by the same harness. It is not a substitute for context engineering, reliable tools, verification, or an eval set. ### Slide 22 — Codex is the harness anatomy made visible **Job:** Map the theory into a product the audience can use immediately. Return to the master map and attach real Codex Mac app features to its responsibilities: provider and project instructions, tool discovery, terminal execution, file editing, repository search, browser tools, skills, compaction events, screenshots, visualizations, ask-user interactions, subagents, permissions, and verification. The quantity and variety of tools is itself instructive. A tool can even locate other tools. What appears to be a chat box is a model inside a large and evolving harness. The section should use published, open-source, and directly observable behavior. It must not expose private system prompts or hidden reasoning from this task. Current official documentation and source should be refreshed near delivery because the product evolves quickly. Claude Code is a brief contrast, not a bake-off. It can illustrate equivalent anatomy or a particularly legible implementation choice after that behavior is verified. Claims about Fable, safety classification, or model downgrading must be confirmed before inclusion. The practical lesson is to specify the goal, durable context, constraints, available tools, and proof of completion. Repeated guidance belongs in repository instructions. Repeated workflows can become skills. Consequential actions belong behind permissions. Important work requires tests or another verifier. ### Slide 23 — This presentation is a harness trace **Job:** Close with reality rather than a manufactured case study. This slide remains intentionally blank until Slides 1–22 exist. At that point, this task will be audited for genuine evidence: handwritten sketches, voice notes, the successive plans, the slide-by-slide interview, loaded skills, source research, tool calls, rejected visual directions, critiques, eval criteria, and completed artifacts. The real artifacts will be placed at their corresponding locations on the master harness map. The three attractive but insufficient storyboard variants may be useful because the failure produced a better evaluation target: the problem was not merely style but the lack of genuinely different visual thinking. They should appear only if that episode remains representative of the final process. The ending should do two things. For people who mainly use agents, it should demystify what is happening. For people who intend to build them, it should make the system feel understandable and achievable. The final words should emerge from the completed process rather than being locked prematurely. --- ## 6. Visual constitution The presentation now has a working visual constitution: a stable set of characters, transformations, and meanings that should survive whatever final rendering style is selected. This constitution is not a slide template, color palette, or commitment to 3D imagery. It defines what the recurring objects mean and how they are allowed to change. The same concepts could later be expressed through premium industrial rendering, hand-drawn whiteboard diagrams, physical maquettes, CAD drawings, or a hybrid system without changing their underlying logic. The governing metaphor is: > Training refines the object. The loop gives it motion. The harness makes that motion useful and controllable. An agent begins as raw human material compressed into a model. Training progressively refines that model, giving it more useful behavior and fewer dangerous or unproductive edges. It becomes increasingly rounded, but never perfectly round. The harness does not finish training the model or remove its remaining imperfections. It surrounds the faceted model with the machinery that allows it to roll reliably: context, tools, memory, permissions, execution, verification, and learning. ### The model is one persistent character The source material begins as a vast field of fragments: particles, shards, tokens, language, code, images, and traces of human activity. It should feel abundant and chaotic rather than like a tidy database. Pretraining compresses this diffuse material into one dense, sharply faceted object. The base model is powerful but unfinished. A tetrahedron or similarly simple polyhedron communicates both compression and sharpness. Post-training does not replace it with a new character. The same core gains more faces, fitted behavioral layers, or other visible refinements while remaining recognizable. These additional faces mean behavioral refinement; they must not accidentally imply a larger parameter count or a different model. When the assistant learns tool use, the model gains standardized ports, sockets, keys, or attachment points. These are interfaces through which the model can request external action. They must not imply that the model itself browses, runs code, queries a database, or performs the action. The model asks; the harness executes. The agentic model becomes substantially more faceted and therefore closer to round. It can participate productively in a repeated model–action–observation loop: inspect a result, notice failure, revise its approach, and continue. It is increasingly ready to roll, but it still rolls unevenly. ### The loop is motion The loop is not another character or decorative circular arrow. It is the repeated motion of: > context → model → proposed action → external execution → observation → model again It should first appear in its smallest comprehensible form. Complexity is introduced around it only after the audience understands this motion. The loop continues when more work is required, exits when completion has been independently verified, or stops because it has reached a permission, safety, time, cost, or turn boundary. The model’s confidence does not open the exit. Long-horizon reinforcement learning can teach a model that a failed observation is a reason to inspect, revise, and try again. At inference time, the harness still has to make the failure observable, return useful evidence to the trajectory, and enforce a trustworthy exit or escalation rule. ### The harness is engineered accommodation The harness is a separate engineered environment surrounding the loop and the imperfect model. Its most compact visual expression is a flawless transparent sphere, bearing, gimbal, or carriage surrounding a still-faceted core. The larger expression includes the engineered rails, switches, signals, stations, and service lines that direct the carriage through work. The core remains visible and unchanged. The carriage stabilizes it; the rail system supplies direction, branching, boundaries, and a route toward a verified outcome. The complete harness is not merely a sphere or a sequential row of boxes. When the talk opens its anatomy, the metaphor must expand into the truthful topology described in Section 3. Guardrails are gates before or around expensive motion. Instructions, skills, memory, and retrieval feed context construction. Tools and subagents are conditional branches. Permissions and approvals surround execution. Verification controls the exit. Traces and learning sit beneath or outside the synchronous path. A gate is a permitted and useful recurring mechanism when it depicts a real decision boundary. Every gate must make four things legible: the judge, the evidence the judge receives, the actuator or policy that changes the route, and the destinations for each outcome. The ingress gate may be actuated by deterministic identity, tenant, and rate checks plus a small classifier; its routes are reject-before-loop or admit-to-loop. The verification gate is actuated by tests, artifact state, an independent evaluator, or human review; its routes are return-evidence or exit. A training or promotion gate compares a quarantined candidate against a versioned eval; its routes are keep-quarantined or promote. A decorative gate with no evidence source or honest alternate route is not allowed. The complete anatomy is a map of possible responses to observed failure modes, not a checklist every founder must implement. ### Evidence is the fourth character Every run leaves evidence: tool calls, observations, errors, timing, cost, tests, corrections, human reactions, and downstream outcomes. This evidence should have a consistent identity—tracks, receipts, captured records, impressions, or physical test specimens—so the audience can distinguish something that actually happened from another model-generated opinion. Evidence verifies the current trajectory and improves future trajectories. A captured failure becomes a reusable eval when it preserves enough information to replay the situation and judge a new outcome. The dominant improvement path normally changes the harness: its context, prompt, tool, retrieval, memory, permissions, workflow, or verifier. Only selected, well-understood evidence eventually returns to the model-training process. Not every failure should be melted back into the model. ### Permanent visual meanings These meanings should remain stable throughout the deck: - particles or dust mean raw training material; - a faceted solid means the model and its learned behavior; - additional faces or fitted layers mean refinement through training; - ports and attachment points mean model-visible tool interfaces; - repeated motion means agentic inference; - a perfectly round enclosure means the local harness stabilizing the active model; - substantial main rails mean the synchronous execution path; - narrower maintenance rails mean asynchronous evidence, evaluation, and improvement; - stations mean specific harness responsibilities; - switches and sidings mean conditional tools, retrieval, or delegation; - gates mean real decision boundaries in guardrails, permissions, approvals, verification, or candidate promotion; each gate needs a visible judge, evidence source, actuator, and honest destinations; - tracks, residue, or records mean traces and production evidence; - returning evidence means experimentation, improvement, or—when explicitly shown—training; - a visible, separable core means the model remains imperfect and distinct from its harness. - warm gold seams mean the incumbent or currently deployed model; - cool teal seams mean a candidate or successor version produced by an explicit learning experiment. A shape or seam color should never change merely to make a slide look different. Every change must communicate a change in capability, responsibility, state, or version. ### Approved concept studies The following studies test the constitution’s hardest ideas. They are not finished slides or a final art direction. Their neutral physical-maquette treatment was chosen to remove typography, layout, branding, and decorative style from the evaluation. What matters is whether the metaphor is understandable. #### Study 1 — Raw material becomes a base model ![Diffuse data material compressed into a faceted base model](/thread-artifacts/15-generated-01.jpg) Diffuse charcoal fragments tighten into one dense tetrahedral core. The material remains visibly continuous across the transformation, establishing pretraining as compression of distributed human-produced patterns into a powerful but unfinished predictive object. This concept should anchor Slide 1 even if its final medium changes. #### Study 2 — One model undergoes progressive refinement ![The same model progressing from base model to assistant, tool user, and agentic model](/thread-artifacts/15-generated-02.jpg) The same core progresses from a sharply faceted base model to an assistant with fitted behavioral facets, a tool-capable model that can speak a standardized request protocol, and an almost-round agentic model that can use returned observations productively. The study establishes continuity: these are not four unrelated products but successive refinements of the same underlying model. The final object remains faceted because agentic post-training improves the core without making it dependable on its own. Transparent glass appears only when the separate production harness is introduced. #### Study 3 — The harness makes an imperfect core roll ![A faceted model stabilized inside a transparent spherical harness](/thread-artifacts/15-generated-03.jpg) The still-faceted model sits unchanged inside a separate transparent bearing and gimbal. The engineered exterior, not the core, provides stable motion along a path. This is the most compact expression of the talk’s central distinction: the model supplies capability; the harness repeatedly creates the conditions in which that capability can travel toward an outcome. #### Study 4 — A failed trajectory becomes a harness improvement ![A production trajectory leaving evidence that becomes an eval and returns to the harness](/thread-artifacts/15-generated-06.jpg) A completed run leaves persistent records. A failed record is selected, inspected, and converted into a reusable test that returns to the outer system. The faceted model stays unchanged while the harness receives the correction. Fine-tuning was deliberately removed from this study because it competed with the primary idea. This is the default learning-loop story: replay and improve the harness before changing the model. #### Study 5 — Evidence produces a successor agent ![An incumbent gold agent offloading evidence while a teal successor is built](/thread-artifacts/20-generated-01.jpg) The gold agent travels on the live rail while offloading a black-box record of its run. Evidence is opened, inspected, and selected. In the foreground factory, a second agent is being assembled or tuned from what was learned. Its cool teal seams identify it as a successor rather than an accidental duplicate of the incumbent. This version-to-version image is appropriate when the talk explicitly discusses an experiment that produces a new model or complete agent configuration. It should not imply that every ordinary feedback cycle retrains the model. The seam-color distinction is now constitutional: gold means the current deployed version; teal means a candidate or successor. Color changes only when version identity changes. #### Study 6 — Biopsy of the harness ![The rolling agent wheel separated into its principal harness components](/thread-artifacts/21-generated-01.jpg) The familiar wheel is frozen above one uninterrupted rail and separated along its axle. The outer transparent ring with its signal represents guardrails. The compact stack of plates represents the system prompt and loaded instructions. The faceted charcoal object remains the model. The ring of standardized sockets represents tools. The dark concentric spool represents memory. The opposite glass ring and bearings show how the parts close back into one operable carriage. This is intentionally not the complete topology. It is the visual table of contents for the dissection that follows. Its simplicity allows each part to be recognized again on future slides while real artifacts explain how that component behaves in software. The [earlier network-first biopsy](/thread-artifacts/19-generated-04.jpg) remains useful as design-history evidence. It was rejected because it attempted to show context assembly, the inner loop, tools, subagents, verification, and the learning plane simultaneously. The result was architecturally ambitious but too complex to perform the biopsy’s actual communication job. These studies reveal an important constraint: the early concepts can communicate almost entirely through form. Evidence loops and the complete topology will require a small amount of handwritten annotation, progressive build, or a paired schematic to establish causal direction. That is acceptable. The goal is not to force every technical relationship into a self-explanatory decorative object. ### Visual style remains open The final presentation will use one flexible system rather than a different art direction for every act. Typography, grid, background behavior, palette, numbering, annotations, and source treatment should feel coherent. Within that system, different kinds of truth deserve different visual forms. The opening evolution can use highly polished generated imagery because it explains an abstract transformation. The exploded wheel supplies orientation for the anatomy section. Any separate topology schematic must prioritize execution truth over spectacle. Anatomy slides should prefer literal prompts, schemas, traces, screenshots, transcripts, and charts, with the conceptual visual acting as an anchor rather than consuming the entire slide. The closing slide returns real production artifacts to the learning system. The likely system pairs a limited number of premium core images with authentic hand-drawn annotations and real evidence. Handwriting should feel like genuine iPad annotation, not WordArt or a faux-handwritten display font. A typical slide may contain a short claim title, a few precise supporting points, and one dominant conceptual image or evidentiary artifact. The image does not need to impersonate the entire slide. The earlier storyboard images remain useful as evidence of a rejected approach: - [Initial 23-slide storyboard](/thread-artifacts/06-generated-01.jpg) - [Atelier whiteboard variant](/thread-artifacts/07-generated-01.jpg) - [Technical field-notes variant](/thread-artifacts/07-generated-02.jpg) - [Gallery markerboard variant](/thread-artifacts/07-generated-03.jpg) Those variants attempted to solve complete-slide composition before establishing a recurring visual grammar. They changed surface styling more than visual reasoning and made it difficult to distinguish a weak concept from a weak design treatment. Future image work should begin with isolated conceptual objects or relationships, verify that they communicate, and only then place them into slide layouts. --- ## 7. Reusable contract for anatomy slides Slides 8–15 should answer the same questions even though their visual forms differ: 1. Why does this component exist? 2. Where does it sit in the live or asynchronous flow? 3. Is it deterministic software, a model call, or a mixture? 4. What characteristics matter if a model is used? 5. What does failure look like? 6. What control, evidence, or eval improves it? This repeated explanatory contract gives the audience stability while the underlying examples change. It should mainly live in the speaker notes and visual hierarchy rather than appearing as six repeated labels on every slide. --- ## 8. Evidence and accuracy ledger The following claims require verification before slide production: | Claim or example | Current status | Required action | | ----------------------------------------------------- | -------------------------------------------- | ----------------------------------------------------------------------------------------- | | OpenAI Harmony roles, channels, and tool structure | Candidate public implementation artifact | Use current official public specification; do not imply access to hidden chain-of-thought | | Train-time RL and test-time-compute scaling | Supported by OpenAI o1 material | Refresh official source and reproduce only defensible curves or wording | | Models increasingly exhibit long-horizon persistence | Directionally credible but broad | Support with current model documentation or present as an observed trend | | Ralph loops and current usage | Timely but culturally fluid | Define briefly and avoid making it foundational | | Mastra observational-memory accuracy and architecture | Mastra-published evidence exists | Attribute results to Mastra and verify current research/version | | Observational memory and “90% cheaper” | Too broad as stated | Replace with prompt-cache mechanism and a transparent scenario-specific calculation | | Chipotle bot used as an unintended coding backend | Candidate public incident | Include only with a sourceable factual account | | Home Depot incident | Unverified | Exclude unless primary or strong public evidence is found | | OpenClaw/email prompt-injection scenarios | Primarily threat-model examples | Label as scenarios unless a sourced incident is used | | Claude Code first-message token cost | Potentially observable but version-dependent | Measure or source the current public behavior and date it | | Claude Code Fable/safety downgrade behavior | Unverified implementation claim | Confirm from public documentation/source or omit | | Artificial Analysis “Omniscience Index” | User recalls using it | Verify exact benchmark name, methodology, date, candidates, and screenshot | | CEP Dreamer evaluation | Real internal example | Select representative cases, sanitize outputs, preserve truthful scores and economics | | Karpathy Software 1.0/2.0/3.0 analogy | Candidate framing | Verify the exact terminology and use only if it improves Slide 15 | | Cursor fine-tuning Kimi from accept/reject data | Candidate public case | Verify model version, data, method, and public source or replace | | Current model names, prices, context, latency | Highly perishable | Refresh immediately before slide authoring and date every comparison | | Codex and Claude Code anatomy | Rapidly evolving | Use current official documentation, open source, and observable behavior | | External “autocomplete to assistants” artwork | Inspiration only | Create an original reinterpretation unless reuse rights are confirmed | Reported benchmark results must be labeled as reported results. A framework’s terminology should not be presented as an industry standard. Public benchmarks shortlist models; only the presentation’s private task eval can support a private task conclusion. --- ## 9. Confidentiality and evidence boundaries The final presentation may use sanitized CEP and dealership examples, but it must not expose customer names, dealer identifiers, tenant information, private prompts, proprietary architecture details, sensitive production metrics, or hidden reasoning. Screenshots should be selected because they prove a claim, not because the slide needs texture. Every screenshot must be reviewed for names, IDs, URLs, message content, credentials, private model configuration, and unintended metadata. Codex and Claude Code should be explained through public documentation, open-source material, and behavior visible to an ordinary user. Private system instructions from this task are out of scope. --- ## 10. Production deliverables The intended final package is: - this Markdown master plan as the durable source of truth; - a research dossier containing dated sources and approved claims; - the selected master harness map and its editable source; - a 27-slide 16:9 PowerPoint; - complete speaker notes containing the argument, transitions, qualifications, examples, and citations; - sanitized evidence assets from CEP, Codex, and the presentation-production process; - a timed rehearsal version and final source/accuracy audit. There will be no live demo. Code appears only where a short real excerpt is the clearest explanation, particularly the agent loop, tool contract, or prompt anatomy. There is no vendor scorecard, separate security lecture, or technical appendix unless the deck later proves impossible to deliver cleanly without one. --- ## 11. Verification and acceptance tests ### Narrative audit Every section must answer a question created by the prior section: 1. How does a predictive model become agent-capable? 2. Why does that capability still require a harness? 3. What are the harness’s major organs and where do they sit? 4. Why does one apparent agent contain several models? 5. How are those models selected using evidence? 6. How do production outcomes become repeatable improvement? 7. How do Codex and this presentation embody the same anatomy? ### Technical audit Challenge every causal distinction likely to attract scrutiny: - statistical learning versus literal internet storage; - role delimiters versus the broader post-training process; - train-time reinforcement learning versus inference-time reasoning; - agent-capable model versus agent loop versus harness; - context sources versus sequential processors; - prompt guidance versus executable enforcement; - model-proposed actions versus harness-controlled execution; - memory recall versus cache economics; - external benchmarks versus task-specific evals; - production telemetry versus curated training data; - model confidence versus verified completion. ### Cold-reader acceptance A technically informed founder should be able to use the deck and notes to explain: - the inner agent loop; - the major harness responsibilities and their positions; - why different jobs need different models; - how to shortlist, evaluate, and select a model; - how feedback becomes an eval case before it becomes training data. ### Rehearsal acceptance The complete narration should land between 38 and 40 minutes. The recap and master anatomy remain intact. Later examples are shortened before core definitions are rushed. Every slide has one takeaway title, one primary claim, and one primary evidentiary object. ### Visual acceptance Render and inspect every slide at full size. Verify typography, text wrapping, connectors, progressive builds, screenshot redaction, visual hierarchy, color contrast, clipping, overlap, source annotations, and continuity of the master map. The deck should be legible from the back of a meeting room and should not depend on reading paragraphs from the screen. ### Final making-of acceptance Slide 23 is produced only after the deck contains enough authentic evidence. Its artifacts must correspond to events that actually happened in this task. The final slide should not imply that rejected experiments were planned successes. --- ## 12. Locked decisions and intentionally open decisions ### Locked - The audience is a technically literate founder forum. - The talk is approximately 40 minutes and speaker-led. - The production deck length is 27 slides, composed from 23 durable narrative units plus the title, agenda, dedicated Part I transition, and closing diagnostic. - The narrative begins with model evolution, biopsies a neutral harness, explains multi-model selection and learning, and ends with Codex and the making of the talk. - The technical topology follows a real request lifecycle and distinguishes synchronous, conditional, cross-cutting, and asynchronous responsibilities. - The audience-facing biopsy is the simple exploded agent wheel, not the complete topology. - Codex is the main practical product anatomy; Claude Code is supporting contrast rather than a bake-off. - CEP supplies selective real evidence, especially the Dreamer eval, without becoming the main character. - Fine-tuning is a possible last-mile experiment, not the default destination of production data. - Slide 23 remains blank until the rest of the deck is complete. - The visual constitution is established: one persistent faceted model is refined by training, moved by the loop, made operable by a separate round harness, and improved through captured evidence. - Future image work begins with isolated conceptual relationships and verifies their meaning before attempting complete slide compositions. ### Intentionally open - Whether the final deck needs a separate labeled topology schematic beyond the exploded wheel and the small inner-loop diagram. - The exact final geometry, material, and rendering treatment of the opening model artifact, within the established constitution. - The balance between premium industrial rendering and luxury technical-notebook styling. - The method for producing authentic handwritten annotations. - The exact sanitized CEP screenshots and Dreamer cases. - Any public anecdote or vendor implementation claim that remains unverified. - The final wording and emotional beat of Slide 23. These open decisions are planned design and research checkpoints, not permission for an implementer to improvise. Each must be resolved through a visible prototype, evidence review, or user selection before it propagates through the deck.