Agent Architecture on AIBussin — AI applications, systems and books

Planning and Execution

Sat, 08 Aug 2026 16:35:00 +0100

The critique loop works on one thing at a time. It assumes the task already exists as a candidate we can hold, inspect and improve.

Some tasks have no draft to hold.

Inspect a project, reproduce the failing test, find the cause, patch the code, rerun the relevant tests, and report what changed.

No single narrow action responsibly completes that goal, and the actions constrain each other. Patching before diagnosis is guesswork wearing the costume of work, and reporting success before observing a passing test is a claim about the world that nothing in the run supports. Worse, if execution reveals that an assumption was wrong, the rest of the route may be wrong too. A runtime choosing each action independently can react to the new observation, but without an explicit representation of the intended route it has nothing concrete to compare the changed world against.

Architecting Agent-Based Systems

Mon, 01 Jan 0001 00:00:00 +0000

The previous chapters built up one agentic workflow: roles, tools, memory, reflection, revision, and versioning. This chapter changes scale.

An agent-based system is not one large assistant with a bigger prompt. It is a collection of components that divide responsibility, communicate through explicit channels, use shared or separate state, and preserve enough identity that you can tell which part did what.

The design question is:

Which responsibilities belong together,
which should be separated,
and how should the separated parts coordinate?

Architecture begins when those boundaries have to be chosen deliberately.

Memory and Selective Recall

Sat, 08 Aug 2026 17:14:00 +0100

The capability boundary gave the agent a defined action space and a rule for which capabilities are eligible at each step. Runtime state gave it an explicit working representation of what this run has established so far and how it reached that point. Together they govern the current execution, but neither gives information from an earlier run a controlled way to influence this one. There is a family of failures that requires exactly that.

Building the Complete Agent

Wed, 26 Aug 2026 10:00:00 +0100

Every mechanism in this book was argued against a problem chosen to isolate it.

That isolation was deliberate, and it was also a form of protection. The memory chapter picked a task where recall was the bottleneck, held everything else still, and measured the one thing it came to measure. The result is a clean explanation and a weak claim. Nothing in it establishes that the same retrieval policy behaves when a search controller is expanding forty nodes, or when a verifier insists that every piece of evidence carry a state identity the search controller has never heard of.

Building Systems That Distrust Their Models

Sun, 30 Aug 2026 21:01:00 +0100

The first chapter began with a simple observation:

A language model can produce a fluent answer
without possessing a mechanism that proves the answer is true.

Fourteen chapters later, that fact has not changed.

The model can still:

invent
misbind
misattribute
ignore decisive context
answer without enough evidence
accept bad retrieval
repair one error by creating another
repeat its own stored mistake

The final architecture does not make those possibilities disappear.

Advanced Agents From First Principles 23: Your Infrastructure Is Healthy. Why Is the Agent Getting Worse? Detect Behavioral Drift and Roll Back Safely

Sun, 09 Aug 2026 12:00:00 +0100

Your Infrastructure Is Healthy. Why Is the Agent Getting Worse?

Your dashboards are green.

The model endpoint is responding.

The browser workers are alive.

The database is healthy.

The queue is draining.

The verifier service is up.

Latency has not exploded.

There are no obvious exceptions.

And yet the agent is getting worse.

It fixes fewer bugs.

It retrieves weaker evidence.

It escalates to expensive models more often.

It chooses the wrong tools more frequently.

Advanced Agents From First Principles 21: What Happens When Too Many Agents Compete for the Same Resources? Add Admission Control, Quotas and Backpressure

Sun, 09 Aug 2026 11:21:00 +0100

What Happens When Too Many Agents Compete for the Same Resources?

A single agent can look healthy in isolation.

It gets a request.

It calls a model.

It launches a few search branches.

It opens a browser.

It runs tests.

It asks a verifier to check the result.

Everything works.

Then production traffic arrives.

Ten agents start at once.

Then fifty.

Then five hundred.

Now every agent still has a perfectly reasonable local plan.

Advanced Agents From First Principles 20: Can Your Agent Coordinate Across Machines Without Duplicating Work? Use Leases, Idempotency and Fencing

Sun, 09 Aug 2026 11:13:00 +0100

Can Your Agent Coordinate Across Machines Without Duplicating Work?

A single-process agent can already be complicated.

It can plan.

It can search.

It can launch speculative branches.

It can cancel losing work.

It can verify outcomes.

Then you move that work onto multiple workers.

Now a new class of failure appears.

Two workers both believe they own the same task.

One worker pauses for thirty seconds.

Another worker assumes it died and takes over.

Advanced Agents From First Principles 19: Can Your Agent Explore in Parallel Without Creating Chaos? Use Speculative Execution and Early Cancellation

Sun, 09 Aug 2026 11:10:00 +0100

Advanced Agents From First Principles 19: Can Your Agent Explore in Parallel Without Creating Chaos? Use Speculative Execution and Early Cancellation

A production agent often has more than one useful thing it could do next.

It could:

inspect repository state,
run a targeted test,
retrieve documentation,
ask a second model to critique a candidate,
generate an alternative implementation,
probe an API,
inspect a deployment,
or verify an invariant.

If those actions are independent, executing them one by one can be needlessly slow.

Advanced Agents From First Principles 18: What Should Your Agent Observe Next? Use Expected Value of Information

Sun, 09 Aug 2026 11:06:00 +0100

What Should Your Agent Observe Next?

Your agent is uncertain.

That does not tell you what to do.

In the previous post we split uncertainty into operational categories:

interpretation uncertainty,
evidence uncertainty,
route uncertainty,
state uncertainty,
tool uncertainty,
candidate uncertainty,
verification uncertainty.

That is already better than one generic confidence score.

But it still leaves a harder question:

Which piece of information is worth buying next?

Suppose a coding agent is trying to fix a failing test.

Advanced Agents From First Principles 17: What Is Your Agent Actually Uncertain About?

Sun, 09 Aug 2026 11:02:00 +0100

What Is Your Agent Actually Uncertain About?

An agent reaches a difficult point in a task.

It is not sure what to do next.

A common implementation responds like this:

uncertain
 ↓
call the model again
 ↓
still uncertain
 ↓
call a stronger model
 ↓
still uncertain
 ↓
search more

That is not a reasoning strategy.

It is a spending strategy.

The system is using more computation without identifying what information is actually missing.

Advanced Agents From First Principles 16: Where Should an Agent Spend Its Compute? Build a Dynamic Budget Scheduler

Sun, 09 Aug 2026 10:53:00 +0100

Where Should an Agent Spend Its Compute?

A production agent has a budget whether you designed one or not.

Every model call costs something.

Every search node costs something.

Every tool invocation costs something.

Every verifier costs something.

Every retry adds latency.

Every escalation to a stronger model spends money and time that could have been used somewhere else.

The naive architecture gives every subsystem its own fixed limit:

MAX_STEPS = 20
MAX_SEARCH_NODES = 32
MAX_CRITIC_CALLS = 3
MAX_RETRIES = 4
MAX_VERIFIER_CALLS = 2

That looks safe.

Advanced Agents From First Principles 15: How Do You Optimize an Agent Policy Without Turning It Into Another Black Box?

Sun, 09 Aug 2026 10:49:00 +0100

How Do You Optimize an Agent Policy Without Turning It Into Another Black Box?

By now our advanced agent can do a lot.

It can:

route tasks to different models or specialists,
decide whether to search,
choose a search budget,
decide when to escalate,
invoke critics,
retry or recover,
stop when evidence is strong enough,
learn from verified production trajectories,
and trace the decisions that produced each outcome.

That creates a new problem.

Advanced Agents From First Principles 14: Can Your Agent Learn From Its Own Trajectories Without Learning the Wrong Lessons?

Sun, 09 Aug 2026 10:33:00 +0100

An advanced agent now leaves behind something extremely valuable:

evidence.

Not merely chat history.

Not merely model outputs.

Not merely traces.

A sufficiently instrumented system can record:

what state it was in,
what alternatives it considered,
which route it selected,
what branches it pruned,
which model or specialist it escalated to,
which tools it called,
which critic changed the answer,
what verification evidence was produced,
how much compute was spent,
and whether the final result actually passed.

That immediately suggests a tempting idea:

Advanced Agents From First Principles 13: How Do You Debug an Agent That Made the Wrong Decision? Add Trajectory Observability

Sun, 09 Aug 2026 10:18:00 +0100

An advanced agent fails.

You look at the final answer.

It is wrong.

So you inspect the prompt.

The prompt looks reasonable.

You inspect the model response.

That also looks reasonable.

But somewhere between the original request and the final result the system:

chose the wrong specialist,
pruned the branch that contained the right solution,
trusted a critic that was wrong,
escalated to an expensive model unnecessarily,
failed to escalate when it should have,
retrieved stale memory,
spent most of its budget exploring duplicates,
accepted a weak verifier signal,
retried the same strategy under a different name,
or transformed a local success into a global failure.

The final answer does not tell you which one happened.

Advanced Agents From First Principles 11: Which Advanced Agent Architecture Should You Use? A Practical Selection Guide

Sun, 09 Aug 2026 09:20:00 +0100

Which Advanced Agent Architecture Should You Use?

You now have too many options.

That is a better problem than having none.

But it is still a problem.

You can add:

self-consistency,
Tree of Thoughts,
beam search,
Monte Carlo Tree Search,
evolutionary search,
specialist routing,
planner/executor/critic separation,
multi-agent debate,
adaptive policies,
learning from previous runs,
or a mixture-of-agents runtime that chooses among several of them.

The temptation is to combine everything.

Advanced Agents From First Principles 29: When Should an Agent Stop and Ask a Human? Design Authority Boundaries and Escalation