Agent Lifecycle

The Bullet Protocol uses a turn-by-turn execution model where the system decides what capabilities to load at each step. Instead of giving an agent everything upfront and hoping it follows instructions, the system explicitly controls what's available on each turn.

Why This Matters

Traditional approaches dump all capabilities into the system prompt and trust the agent to figure it out. This breaks down as conversations get longer or more complex. Agents ignore context, use the wrong tools, or miss important constraints.

The Bullet Protocol flips this model. After each user message, a hook fires and runs a router that decides exactly what bullets to load for the next response. The agent doesn't choose its capabilities—the system assembles the right context programmatically.

This trades some agent autonomy for much better reliability. Complex workflows run predictably because execution is explicitly controlled rather than emergent.

How a Turn Works

Every interaction follows the same pattern. Understanding this flow is key to understanding how the system operates.

User sends a message

The conversation moves forward. Maybe the user is starting a task, answering a question, uploading data, or continuing a workflow. The system receives this message and the next phase begins.

Hook fires and router takes control

Before the agent sees anything, a hook fires. This is the control point where the router takes over.

The router looks at the full picture: what's been discussed, what plans are running, what data is available, what the user seems to want. It builds a complete understanding of the current state.

Then it decides what bullets the agent needs. If a plan is executing, the router loads whatever that step requires—scripts, data, guidance. It searches for relevant guidance bullets using semantic search and quality rankings. It identifies available data and decides whether to load summaries or full content. It ensures any needed scripts have their definitions and dependencies loaded.

Resolution fills in the blanks

For each bullet the router selected, resolution figures out the concrete instance to use.

If the plan needs data and the user uploaded a file earlier in the conversation, resolution wraps that upload as an ephemeral data bullet. If the user has saved bullets in their private namespace, resolution finds and reuses them. If nothing exists yet, resolution generates new bullets on-the-fly—fetching from APIs, running queries, or processing available content.

Users can also specify exact bullets explicitly. The system respects those choices and uses exactly what was requested.

Context gets assembled

Now the resolved bullets get formatted into the agent's context.

Plans appear as structured workflows with the current step highlighted. Guidance shows up as instructions—tactics and best practices relevant to this moment. Data appears as summaries (large datasets don't bloat context; the agent can fetch full content if needed). Scripts include their signatures and input requirements so the agent knows how to use them.

The assembled context is precisely tailored. Nothing extra, nothing missing.

Agent responds

Only now does the agent see the user's message and the assembled context. It has exactly what it needs to respond effectively.

The agent generates its response using the loaded bullets. When done, control returns to the user. The cycle repeats on the next message.

What the Router Does

The router is the intelligence layer that makes capability decisions. It works through several phases.

First, it analyzes conversation state: Is a plan executing? What tasks are active? What data exists? What happened last turn? This builds the foundation for all other decisions.

Then it recognizes intent: Is the user starting something new? Answering a question? Providing requested data? Fixing a mistake? Intent shapes which bullets matter.

If a plan is running, the router tracks execution: Which step are we on? What does it require? Are all preconditions met? Are there placeholders that need resolution? The router ensures steps execute in order with everything they need.

The router continuously discovers relevant guidance using semantic search against the conversation context, filtered to the user's namespace and global curated bullets, ranked by quality metrics. Every turn might load different guidance based on what's relevant now.

When plan execution hits a placeholder, the router resolves it by analyzing requirements, searching for existing bullets, potentially creating new ephemeral bullets, validating candidates, and binding the selected bullet. This happens fresh each execution, making plans reusable across different contexts.

Finally, the router makes final assembly decisions: which bullets to load, how to format them, what precedence rules apply if guidance conflicts, whether to create ephemeral bullets to fill gaps. This produces the context the agent receives.

Placeholders and Late Binding

Plans use placeholders to defer specific choices until execution time. Instead of hardcoding "use this exact data bullet," a plan says "I need data that looks like this." The router figures out what to use based on what's actually available.

When execution reaches a placeholder, resolution happens through discovery (finding existing bullets), context inference (using data already in the conversation), or on-demand generation (creating new bullets). The resolved bullet binds to that placeholder for the rest of execution, and the manifest records exactly what was used.

See Plan Placeholders for more details on how this works.