HatShift: a single-agent orchestration pattern

Multi-agent systems are useful, but they can carry an expensive habit: every agent often needs the same core context, rules and operating boundaries before it can do useful work. The more roles you add, the more often that foundation is repeated.

HatShift is a pattern for a different shape of orchestration. One agent keeps the persistent core. Focused role files are loaded when the current task needs them. The role changes, but the core rules and validation boundary stay in place.

The basic flow

The pattern has four moving parts:

1. Core rules hold the instructions, safety boundaries and project-wide standards that apply to every task.
2. A structured trigger identifies the kind of work in front of the agent.
3. A role file supplies focused guidance for research, planning, building, security review or writing.
4. Validation checks the result against the same shared rules before it is accepted.

The agent does not become five independent workers. It remains one persistent worker that can put on the right hat for the current stage.

Why a persistent core matters

A persistent core gives every role the same understanding of the project. File boundaries, language standards, safety requirements and output expectations do not need to be rebuilt for each hand-off.

That can make the workflow easier to reason about. Research and build guidance may differ, but both operate inside the same project context. A security role can challenge a proposed implementation without losing the constraints that shaped it.

Use roles as focused modules

A role file should be small enough to be specific and stable enough to reuse. It does not need to restate the whole project. It only needs to answer what this role changes about the agent’s current behaviour.

A practical set might include:

• RESEARCH.md for evidence collection and source quality
• PLAN.md for sequencing, dependencies and acceptance criteria
• BUILD.md for implementation and verification
• SECURE.md for threat review and defensive checks
• WRITE.md for clear documentation and handover

The trigger that selects a role should be explicit and inspectable. A small JSON object works well because it can identify the role, task and required output without relying on fuzzy intent detection.

Keep validation outside the role

Roles should help produce the work, but they should not be allowed to redefine what counts as acceptable. Shared validation belongs in the persistent core.

That separation is the guardrail. A build role can decide how to implement a feature, but it cannot quietly remove required tests. A writing role can improve presentation, but it cannot change verified facts. A security role can identify risks, but it must distinguish observed evidence from inference.

The cost model is illustrative

The HatShift diagram compares a five-agent baseline with one persistent agent using five role modules. Under the example assumptions shown, repeated core context produces roughly 55,000 tokens, while the HatShift scenario uses roughly 7,800. The graphic models a cost reduction of up to about 70 per cent.

Those numbers are an illustration based on the stated 2026 API pricing assumptions. They exclude tools and caching and are not a production benchmark. Real savings depend on model choice, prompt size, cached context, tool calls and how much work can genuinely share one core.

When I would use it

HatShift is a strong fit for a workflow that moves through related stages, such as investigating a codebase, planning a change, implementing it, reviewing security and writing the handover. It is less suitable when several tasks must run at the same time or need strict isolation from one another.

The useful question is not “one agent or many?” It is “how much context is truly shared, and where does independent execution add enough value to justify the extra coordination?” HatShift gives the single-agent side of that decision a clear, modular structure.