Runtime alignment

Most agent work today is a conversation. You describe what you want, the agent goes off and does it, and you read what comes back. For small tasks that's fine. As the work gets longer, and as one agent becomes a team of them, the conversation stops being enough, and things go wrong in the same handful of ways every time.

The agent drifts from what you actually asked for, because your intent lives only in a chat that keeps growing. It makes decisions that were yours to make, because asking is more work than deciding. A group of agents reviews the work and agrees it's done, and agreement turns out to say very little about whether it's right. Hours into a task, the details that mattered get summarized away. Agents wait on each other, poll, loop and stall. And somewhere along the way, one of them does something it was told not to do.

What I mean by it

Most conversations about alignment are about training, meaning what a model values and how it behaves before it ever ships. That work matters, and it's mostly the model makers' job. The problem I work on is different. I call it runtime alignment: keeping an agent doing what you actually intended while it runs, in your environment, on your work, over hours, alongside other agents.

A well-trained model can still drift from the task in front of it, settle questions that weren't its to settle, or get talked into something by a document it reads. None of that is fixed by a better model alone. Runtime alignment lives in the system around the model. The agent works within limits it can't cross, and its work comes with evidence you can check.

How to build for it

None of the failures above is a model problem you can prompt your way out of. They're structural problems, and they have structural answers. It starts with a split. The person defines the goal, and steps into the path only when it matters. The agent's job is to reach that goal in a way the person would recognize as reasonable. Write the intent down somewhere the agent can't rewrite. Limit what the agent can do instead of asking it to behave. Check the work independently, against reality. Keep people at the decisions that are actually theirs. I think of this as intentional agentic work, and this series is how I approach each piece. It isn't about watching agents more closely. Done well, people make fewer decisions, and better ones.

Most examples come from personal research systems I've built and run, primarily egg, an open-source testbed for these ideas. Attention is all you need (to protect) also draws on an AI code reviewer I built and ran in production. They come from software, but the ideas apply to any knowledge work you'd hand to agents: research, drafting, analysis, review.

The series

Why it matters: attention is all you need (to protect). Human attention is the scarcest resource in AI-assisted work. AI output can spend it or save it, and people can only choose where to spend it once they trust what the agent did. Runtime alignment is how that trust gets earned.

Intent: give agents a contract, not a conversation. The work is defined in a structured document that lives outside the chat. Each role can change only its own part, decisions owed to a person are tracked until they're answered, and the plan gets checked before anyone starts working on it.

Memory: reseed, don't compact. Long, structured work shouldn't depend on a summarizer deciding what to forget. Keep a small, fixed core of instructions that holds the intent, fetch everything else when it's needed, and rebuild from that core on purpose.

Verification: agreement isn't verification. When agents agree, that shows their reasoning is consistent. It doesn't show the work is correct. Done means checked against reality, with findings backed by evidence and reviewers who form their own view before reading the author's.

Coordination: teams, not swarms. A team of agents needs a protocol. That means deciding who reviews whom, how agreement converges and how to keep the team from deadlocking.

Control: the model owns judgment, code owns the clock. Waiting, sequencing and state belong in plain, predictable code. Models should only be asked to judge, never to keep the loop running.

Boundaries: stop telling agents what not to do. A rule in a prompt is a suggestion. Take the capability away instead, and give agents connections to your tools and data with enforceable boundaries.

Measurement: measure the system, not just the model. Evaluate the parts nobody evaluates, like the monitors and the harness, and track cost so that a missing number shows up as missing instead of as free.