When choosing an agent framework, I first want to understand which decisions it will make for us.

The model-and-tool loop is only part of the system. We also need to decide what information the model receives, where task state lives, how actions are checked, and what happens after an interruption. A framework can provide useful implementations of those mechanisms. Its defaults also become part of the product’s behavior.

My starting preference is a thin implementation close to the model API. That makes it easier to inspect the loop and identify where the task fails. I would adopt a framework when I can name the complexity it removes and understand the behavior it introduces.

Three areas deserve particular attention.

State that survives interruption

Conversation history is a record of interaction. It is not always a reliable description of the current task.

For example, a coding agent may attempt several approaches, change files, run tests, and then resume with a compressed conversation. The repository shows the files that exist now. Test results provide evidence about those files. A task record identifies unfinished work.

I want those sources to be explicit. A summary can help the model navigate them, but it should not become the only account of what has happened.

Verification suited to the task

A model’s statement that it completed the work is a claim to check.

For code, that might mean running tests and inspecting the resulting changes. For a research workflow, it might mean checking that cited evidence supports the conclusion. Some tasks still require a person to judge the result.

A separate evaluator can help, but it also needs evaluation. Two model calls agreeing does not establish correctness. I would choose the verification method around the failure we need to detect.

Context selection we can inspect

The system decides which documents, tool descriptions, prior interactions, and intermediate results enter the next model call.

When an agent fails, I want to inspect that selection. Did it receive the relevant evidence? Was the evidence current? Did a summary omit a constraint? Did irrelevant material crowd out what mattered?

These questions are difficult to answer if context construction is hidden behind abstractions we cannot observe or change.

What changes with better models?

I expect some orchestration to become unnecessary as models improve. Prompt workarounds and rigid decomposition rules should earn their place through evaluation.

Durable task state, controlled execution, and verification remain requirements worth examining separately. Better reasoning may change their implementation without eliminating the need for them.

My preference is to keep those boundaries clear and make orchestration replaceable. The framework choice then becomes a practical engineering decision: does it help us build, inspect, and improve the behavior this task requires?

What I was reading

Anthropic engineering posts: