From general harness to domain-specific cognitive flow

Chapter 4 · 5:22–7:36

The practical choice is not simply use a general harness or rewrite the agent from scratch. The talk presents a spectrum:

1. Start with a general agent loop.
2. Add targeted behavior at the loop's insertion points.
3. Move to an explicit, domain-specific sequence when the use case needs more control.

This is a gradual path from a reusable harness to a custom cognitive architecture.

Start with the general loop

A general harness provides a useful starting point because many agent tasks share the same basic pattern: the model receives context, decides what to do, calls tools when needed, observes the results, and continues. The harness can add middleware around those steps without replacing the underlying loop.

For a narrower task, customization can be added selectively. For example, a harness might:

• check a condition before allowing the next model call;
• summarize context when it becomes too large;
• handle a particular tool call in a domain-specific way; or
• add a validation gate before returning a result.

These additions are gates and checks. They constrain or inspect the general flow at important points. They do not necessarily require a new agent architecture.

Teaching context: Think of the general loop as a road and the gates as checkpoints. You can keep the road while adding checks for the requirements of a particular destination.

The speaker's recommendation is to begin with this general harness. It offers the easiest start and the quickest time to value. As the target use case becomes narrower, more checks can be added where they address a demonstrated need.

What “cognitive architecture” means here

In this section, cognitive architecture means an explicit, bespoke sequence that guides the agent through a particular kind of work. Instead of repeatedly letting the model choose the next tool call in a mostly general loop, the harness makes important stages visible and intentional.

This does not mean that the model disappears. The model still performs reasoning and actions inside the system. The difference is that the surrounding harness defines more of the order, branching, and validation of those actions.

The distinction is therefore:

General harness	Domain-specific cognitive architecture
Reuses a common request, model, tool, and observation loop	Defines a sequence for a particular class of task
Lets the model drive much of the next-step behavior	Makes key stages, branches, or gates explicit
Is a fast starting point across many tasks	Adds control when task-specific quality matters more

The talk gives a historical reason for why these explicit designs became attractive. The speaker says that, in 2023–2024, models were not good enough to run reliably in a loop for some demanding tasks. Builders therefore used bespoke multi-step flows to guide the model more carefully. This is a claim made in the talk about that period, not an independently verified training-history conclusion.

Click to enlarge

The slide makes the contrast concrete. Its left side shows a multi-query reporting pipeline. Its right side shows explicit stages for search, planning, execution, and validation. These are not just repeated generic tool calls; they are named parts of a workflow with domain-specific structure.

Example: deep research fans work out across subquestions

Deep research illustrates why an explicit flow can help. Rather than asking one agent to conduct the entire investigation through an open-ended sequence of calls, the system can first generate several subquestions. It then fans out those subquestions, meaning that it sends them into separate research paths that can be executed in parallel or as separate pieces of work. The results are then brought back together for the research output.

The important sequence is:

Main research task
        ↓
Generate subquestions
        ↓
Fan out into several queries
        ↓
Execute the research paths
        ↓
Combine the results into a report

The value of this design is control over decomposition. The harness does not rely on one unconstrained loop to discover every useful subquestion and manage every branch. It gives the work an explicit shape: divide the question, investigate the parts, and combine the evidence.

Click to enlarge

The visible research diagram supports this sequence: one task enters a research-question generator, branches into several queries, and routes their results toward an agent. The adjacent diagram also shows search, planning, execution, and validation stages, although its smaller labels are not fully legible.

Example: a code-review bot can expose its own steps

Code review is another example of a domain where bespoke steps can remain visible. A code-review bot may have a flow that explicitly represents stages such as examining a change, applying review-specific checks, and validating the resulting assessment. The exact nodes of the referenced diagram are not transcribed in the source plan, so the safe lesson is about the structure rather than about additional named steps.

The key idea is that a code-review bot can still use a general harness underneath while presenting a domain-specific flow above it. Much of the behavior may be brought into the harness, but the steps that matter for code review remain explicit. This makes the system easier to reason about as a code-review system instead of treating it as an arbitrary sequence of model-generated tool calls.

Custom flow does not mean a separate universe

It is easy to misunderstand the two approaches as unrelated:

• Mistake: A general harness means there is no customization.
• Mistake: A custom cognitive architecture means the entire agent must be rewritten.

The talk connects bespoke architectures back to loop modification. A domain-specific flow can be built by adding behavior around the common loop, placing gates before or after important calls, and making selected sequences explicit. In other words, customization can be local before it becomes architectural.

This gives a useful progression:

flowchart LR
    A[General harness] --> B[Add targeted gates and checks]
    B --> C[Add domain-specific summarization or tool handling]
    C --> D[Make the cognitive sequence explicit]
    D --> E[Custom architecture for a narrow use case]

The diagram is a teaching model of the progression described in the talk. It does not claim that every project must pass through each stage or that there is a fixed boundary between them.

An operational decision rule

Use the general harness first when the task is broad enough for a reusable loop and when speed to an initial working system matters. Then inspect where the system needs help. Add a gate, check, summarizer, or specialized tool handler at that point.

Move toward a more explicit cognitive architecture when the use case is narrow and excellence requires the system to follow a particular flow. The reason is not that custom is always better. The reason is that a narrow task can justify the extra engineering needed to control its stages and verify its intermediate results.

Situation	Reasonable direction
You need a useful agent quickly across varied tasks	Begin with a general harness
One part of the loop repeatedly causes trouble	Add a targeted gate, check, or handler
The task has a known decomposition with important intermediate stages	Make that sequence explicit
Quality depends on predictable domain-specific behavior	Consider a more bespoke architecture

The speaker's recommendation is incremental: start general, then tune the harness as the task demands more specialization. A custom harness is justified by the requirements of the use case, not by the assumption that generality is inherently inadequate.

The larger lesson

Harness design controls how an agent turns model capability into task behavior. A general harness provides a reusable loop. Gates and middleware shape that loop. A cognitive architecture makes the most important domain steps explicit.

The choice is therefore about how much of the agent's flow should be owned by the harness. As the task becomes more specialized, more consequential, or more dependent on a known sequence, the case for explicit checks and bespoke stages becomes stronger. The next chapter examines another reason to customize: the distance between the task and what the model is familiar with, or its distribution.