Skip to content

How the agents hand off to each other

Berd's built-in agents work as a cast, not a committee. Give one agent one job, keep its useful output in the chat, then hand the thread on when the kind of work changes.

In Berd there is no router that assigns work for you. Orchestration is a visible sequence of handoffs you drive: mention the next agent in the same chat, tell it what to inherit and what to produce, and let it read the conversation above. Tinker's own instructions refer to a Conductor agent that would coordinate the others, but no such agent ships in v0.6.2. Routing is your job.

Two ways to move work

Same chat. The next agent reads everything above it and builds on it. Use this when the work should compound.

Fork the chat. Both branches start from the same shared context and go their own way. Use this when one agent's answer would otherwise anchor the next, and bring the two results back together for a decision.

The three-step funnel

Wildcard, Choosey and Pushback are written as a set, and each of their instruction files names the other two. This is the backbone of most non-trivial work in Berd.

  1. Wildcard diverges. Genuinely different directions, deliberately unranked. It refuses to pick a favourite because that would undo the point of generating three.
  2. Choosey converges. Every option named, the real trade-off stated for each, and a lean with the reasoning attached. The call stays yours.
  3. Pushback strengthens. The chosen direction gets pressure-tested and the weakest load-bearing assumption gets named, with the fix.

The order carries the value. Choosey called too early narrows before there is a field to narrow. Wildcard called after the decision reopens work that should now be getting stronger.

Strong pairings

Debugger to Builder to Debugger

The repair loop. Debugger turns "it is broken" into a reproducible cause and a testable fix. Builder implements the scoped change. Debugger then verifies the original failure is gone and checks the nearest edge case.

Builder works best after the uncertainty is gone. Debugger works best when it is allowed to investigate before anyone starts editing.

Pushback then Copycat

Use this order when a piece of writing needs both stronger thinking and your own voice. Pushback fixes the claim, the structure and the missing evidence. Copycat then rewrites the approved substance in the right voice profile.

Copycat's instructions enforce this from its side: asked to polish something that would change what a sentence claims or how the piece is argued, it stops and points at Pushback rather than making the call. Reversing the order produces well-voiced weak thinking, and then a critique that forces a second rewrite.

Berdy to Tinker

Berdy notices the moment a repeated annoyance should become something permanent. Tinker decides what shape it should take and builds it. Berdy handles the obvious singular case itself; Tinker is for the ambiguous, the multi-piece, or the deliberate sit-down.

Tinker is written to pick up a handoff mid-conversation without restarting it, so do not re-explain what Berdy already covered.

Berdy to Agt. Builder

Berdy spots a way of working that deserves its own character. Agt. Builder turns that spark into an agent with a purpose, a voice and a boundary, and shows it to you before saving.

Come back to Agt. Builder after real use. A concrete miss produces a better fix than a request to make the agent better: "it agreed with a bad idea" is a note, "make it sharper" is not.

Agt. Builder and Tinker, in both directions

These two meet at the line between personality and capability.

  • Agt. Builder when the missing piece is a role, a judgment style or a voice.
  • Tinker when the missing piece is a reusable procedure, an automation, a script or a system with several parts.
  • Both when an agent should be the conversational front end to a reusable skill. Copycat is the shipped example of that pattern.

Agt. Builder will also say plainly when you do not need an agent at all — when you want the same result every time with no voice attached, that is a skill or an automation.

Generalist to a specialist

Generalist is a good first reader for mixed or low-stakes work. It can clarify the request, finish the straightforward parts and reveal which specialist is actually needed. Hand off as soon as the bottleneck is clear, rather than asking Generalist to imitate Wildcard's divergence or Debugger's method.

Pairings that need an explicit order

These combinations are useful and go wrong when both roles are live at once.

Combination What goes wrong Better sequence
Wildcard + Choosey Judging while generating kills the unusual ideas first Generate, then compare
Wildcard + Pushback Critique collapses the idea space before it opens Batch, select, then critique
Choosey + Pushback One compares options, the other improves a single option; together they blur the decision Compare first, strengthen the winner second
Copycat + Pushback Voice and structure are different layers Settle the substance, then the voice
Builder + Debugger Editing while diagnosing hides the original cause Reproduce, implement, verify
Tinker + Agt. Builder Both look like "build an agent" but own different decisions Decide persona, capability or both, then assign each layer

Worked sequences

The wording below is deliberately explicit. A good handoff says what to inherit, what not to redo, and what to return.

Develop a new concept

@Wildcard We have settled too quickly on the first concept. Give me four materially different directions inside the constraints already stated. Do not rank them.

@Choosey Read the options above. Compare all four against time, distinctiveness and reversibility. Give me a lean, not a decision.

@Pushback Pressure-test option 3. Lead with the assumption most likely to sink it, and say what would fix it.

@Builder Turn the revised direction into the smallest working version. Keep the constraints already agreed in this chat.

Diagnose and repair a failure

@Debugger Reproduce the failure from the evidence above. Separate confirmed facts from hypotheses, and stop once you can name the likely cause and a test for the fix.

@Builder Implement the scoped fix Debugger identified. No unrelated refactoring. Report what changed.

@Debugger Verify the original reproduction no longer fails, check the nearest edge case, and tell me whether the evidence supports closing this.

Improve important writing without losing your voice

@Pushback Critique the argument and the structure of this draft. Ignore tone for now. Only the changes that materially improve it.

@Copycat Rewrite the approved version using my work-email profile. Keep the claims and the structure we just settled. Draft only, do not send.

Turn a repeated annoyance into something reusable

Start plainly, with Berdy or Generalist:

I do this every Friday and keep rebuilding the same checklist. Help me finish it once, then tell me whether anything here is worth keeping.

If the shape is unclear:

@Tinker Decide whether this should be a skill, an automation, a small tool or some combination. Give me the trade-off for this case, then propose the smallest concrete build.

If what is missing is specifically a persona:

@Agt. Builder Build an agent for this workflow. Its job is to [purpose]. It should sound [voice]. It must never [boundary]. Show me the proposed agent before saving it.

Explore two approaches independently

Fork the chat once the shared context and the constraints are established.

  1. In one branch, ask Wildcard for the unconventional route.
  2. In the other, ask Generalist or Builder for the straightforward one.
  3. Bring both results into a chat with Choosey.
  4. Run Pushback over the winner before anyone implements it.

Refine an agent after real use

@Agt. Builder Read the agent and the failed exchange above. The specific problem is that it [observable miss]. I wanted it to [desired behaviour]. Propose the smallest instruction change that closes that gap without rewriting the rest of the persona.

The handoff formula

One shape covers almost every case:

@[Agent] Read the thread above. Inherit [decisions and constraints]. Do not redo [settled work]. Your job now is [one role]. Return [specific output].

Filled in:

@Choosey Read the thread above. Inherit the fixed launch date and budget. Do not generate more concepts. Compare the four options already proposed, give me the decisive trade-off for each, and end with a lean.

Learn more