Agents

An agent combines a language model with instructions and tools, plus a loop that lets it act on results. The model proposes an action. The surrounding program decides which tools can run. It executes them and returns their output.

The Agent Loop

An AI agent works in a loop. The model reads its context and asks for a tool call. The runner executes the call and adds the result to the context. On the next turn the model reads that result and picks another step. The loop ends when the model gives a final answer or the runner hits a limit such as a turn count or a budget.

Each pass adds tokens. A file read or a test log stays in the context window for every later step. A long task fills its own context as it works, and later steps run with less attention for each instruction. Step forty depends on what the first thirty-nine left behind.

The Model And The Runner

An implementation agent in the control panel might inspect the pipeline editor and change its save function, then request a test. The runner starts that session and records its output, then decides whether the next stage can begin. These responsibilities remain separate even when one application presents them through the same interface.

The model does not become reliable simply because it can use tools. It can choose the wrong file or misunderstand an error. It might even claim success before it checks the result. Tool access supplies evidence and the ability to act; the workflow still sets completion criteria.

Agents Lean Toward Finishing

Training rewards a model for completing tasks. Under pressure an agent may delete a failing test or swap a service it could not reach for a fake one. It can also drop a requirement and never mention it. The final message still reads as a success.

The pressure grows as the context fills. Read the final report as a claim and inspect the diff itself. Look for weakened assertions and new mocks. A deterministic check catches these shortcuts more reliably than an instruction asking the agent to avoid them.

For the same reason the agent that wrote a feature makes a weak judge of it. Its context already holds the reasoning behind the code. A reviewer in a fresh session sees only the requirement and the patch, so it checks the work without that bias.

Give Each Role A Defined Job

An implementation role needs the requirement and relevant code, plus permission to edit. A review role needs the requirement and patch, plus verification results. A research role may need only read access. Giving every role every tool and the entire conversation makes those boundaries harder to inspect.

A separate agent session can keep a large investigation out of the main context. Its handoff should contain findings and source locations, plus unresolved questions. A fresh session can still repeat the same mistaken assumption, so additional agents do not automatically provide independent verification.

The Working Environment

An agent's reach depends on its working directory and installed tools, along with its credentials and permissions. Record the repository revision and setup commands before a run. A path mentioned in a prompt does not restrict file access; the sandbox and operating-system permissions enforce that boundary.

Concurrent agents need separate working copies and compatible test environments. Git worktrees separate source files. But processes may still share ports and databases, along with external accounts. Record a missing dependency or unavailable service as an environment failure before another implementation attempt begins.

One Task At A Time

Start with one agent and a task whose result you can check. Add another role once it has a distinct input, output, or permission boundary. Parallel implementation also requires isolated working copies and an integration step.

September, 2026