The Thinking Agent

In the last chapter, you built a small agentic workflow in conversation. It had roles, visible state, a tool boundary, and a review loop.

Now we can strengthen the idea that made it useful.

generate
  ↓
critique
  ↓
revise
  ↓
compare
  ↓
accept, reject, or roll back

This is the architecture of a thinking agent: not because the system has private consciousness, and not because a model’s self-critique is automatically reliable, but because the system can externalize an attempt, inspect it, produce a candidate improvement, and decide whether the candidate deserves to replace the current version.

Older agent writing often skips the last step. A revision is not an improvement until something judges it.

Reflection Is a Review Loop

Reflection starts when the system turns its own output into an object of review.

For example:

Write a one-paragraph summary of this paper.

Then evaluate the summary for:
- clarity
- specificity
- usefulness to a technical reader

Identify one weakness.
Revise the summary.
Explain what changed.

This prompt is useful because it creates intermediate artifacts:

version 1
critique
version 2
comparison

Those artifacts can be inspected by the human operator, another role, a deterministic checker, or a later workflow step.

The model may produce the first draft. The model may also produce the critique. But the system should not treat the critique as truth merely because it sounds confident. A critic role is a source of pressure, not an oracle.

The Critic Can Be Wrong

A critic can improve work by naming weaknesses the generator missed. It can also make the work worse.

Common critic failures include:

Reflection needs criteria. Instead of asking “is this good?”, ask what good means:

Evaluate the draft against:
1. preserves the original claim
2. removes unsupported hype
3. keeps the technical term accurate
4. stays under 120 words

Now the critique has handles. You can challenge it. You can compare candidates against it. You can decide whether to accept the revision.

The critic’s most valuable output is often not a score. It is an evidence request: “this claim needs a source,” “this step needs a test,” “this version is clearer but lost a required constraint.” That makes critique useful even when the critic is not the final authority. The system still needs an adjudicator, which may be a human, a deterministic check, a rubric, or a later workflow step that decides whether the revision is accepted.

Prompt Improvement as a Design Loop

Sometimes the weak part is not the agent’s answer. It is the request.

If the result is vague, ask the system to improve the instruction:

I want better results for this task, but my prompt is too vague.
Give me five alternative prompts.
Each should optimize for a different quality:
- precision
- brevity
- evidence
- creativity
- executive usefulness

This does not mean the model has learned your taste permanently. It means you are using the model to search the space of possible instructions.

Example:

Current prompt:
Summarize this academic paper.

Improved alternatives:
1. Summarize the paper's central claim in three bullet points.
2. Explain the paper's method, result, and limitation for a non-specialist.
3. Identify what a practitioner could build from this paper.
4. Compare the paper's claim with one likely objection.
5. Produce a policy briefing: problem, evidence, implication, open question.

The improvement is not the list itself. The improvement is that you now have candidates to compare.

A Worked Reflection Prompt

Here is a compact version of the reflection pattern:

Act as a writing assistant.

Task:
Write a one-paragraph summary of "Attention Is All You Need"
for a technical reader who understands machine learning basics.

Versioning:
- Label the first answer v1.
- Label the revised answer v2.

Review criteria:
- clarity
- technical accuracy
- usefulness
- unnecessary hype

Process:
1. Write v1.
2. Review v1 against the criteria.
3. Revise only where the review identifies a concrete weakness.
4. Compare v1 and v2.
5. Say whether v2 should replace v1, and why.

A useful final comparison might look like this:

| Criterion | v1 | v2 | Decision |
| --- | --- | --- | --- |
| Clarity | clear but abstract | explains self-attention more directly | v2 better |
| Accuracy | mostly accurate | preserves the core mechanism | tie |
| Usefulness | names the paper | explains why it mattered | v2 better |
| Hype | slightly broad | more restrained | v2 better |
| Final decision | keep as baseline | accept as replacement | v2 accepted |

The exact output will vary. That is fine. What matters is the shape:

candidate
  +
criteria
  +
comparison
  =
decision

Versioning Protects Progress

When work improves across several turns, the latest version is not always the best version.

A common failure looks like this:

v1: accurate but dull
v2: clearer and still accurate
v3: more engaging but less precise
v4: shorter but missing the main caveat

Without versioning, you may only have the latest output. With versioning, you can recover the best one.

Versioning can be as simple as a visible log:

[v1.0] Baseline summary.
[v1.1] Improved examples while preserving structure.
[v1.2] Drifted too casual; rejected.
[v1.3] Restored v1.1 and shortened introduction.

In a real application, the runtime might store each candidate with:

version id
input
output
review criteria
critique
decision
accepted / rejected
reason

That record turns a conversation into a manageable process.

Regression Is the Enemy of Reflection

Reflection can create regression.

The system may revise toward a criterion while damaging another. A draft can become more concise and less accurate. A plan can become more ambitious and less executable. A response can become more personal and less safe. A code change can fix one test and break another.

The solution is not to stop revising. The solution is to compare.

This is the practical meaning of agent improvement. The system generates changes and evaluates whether those changes deserve to replace the current version.

What a Manager Role Can Track

In Chapter 4, you used roles manually. In a larger system, a Manager role or orchestration layer can track the revision process:

current_baseline: v1.1
candidate: v1.2
review_status: rejected
reason: lost executive structure
next_action: revise from v1.1, not v1.2

The manager is not valuable because it has a managerial personality. It is valuable because something needs to own the state of the process.

The same pattern applies to code, research, planning, personal routines, and multi-agent collaboration. Once there are multiple attempts, someone or something must track which attempt is current, which is experimental, and which has been rejected.

Teaching Taste Without Pretending to Train

People often say that an agent “internalizes your style” over time. Sometimes that describes the feeling. Mechanically, several different things may be happening:

the current context includes your feedback
the application stores your preference
the system retrieves examples you liked
the prompt now includes stronger criteria
the model provider released a better model

Those are not the same as training the model’s weights.

You can still teach the system what good looks like. Give examples. Name criteria. Preserve accepted versions. Reject bad revisions with reasons. Store durable preferences when the application supports it.

For a writing assistant, a useful preference might be:

Prefer concrete nouns, restrained claims, and short paragraphs.
Avoid generic motivational language and unsupported certainty.

That preference can guide future outputs if it is placed in context or stored as memory. The system has not become conscious of your taste. It has been given a better handle.

The Chapter Pattern

The thinking agent is not a model that magically improves itself.

It is a system that can manage candidates:

current version
  ↓
candidate generation
  ↓
critique
  ↓
revision
  ↓
comparison
  ↓
accept / reject / rollback

That pattern is powerful because it preserves human agency. You can let the system explore without surrendering the decision about what counts as better.

Once several roles, memories, tools, and versioned outputs need to work together, the problem changes scale. We are no longer designing a single agent. We are architecting an agent-based system.