AGENT PROFILE · HOW THE AGENTS HAND OFF TO EACH OTHER

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.

For the ordinary hand-off in one Berd chat, you run it. Type @, choose the next agent and send the assignment. Selecting the mention changes the persona for that turn; the new agent receives the conversation above as context. An agent may suggest who should take the work next, but writing another agent's name in its answer does not wake that agent or transfer control.

Who runs a Berd hand-off?¶

Three mechanisms are easy to call a hand-off, but they work differently.

Mechanism	Who starts it?	What moves?	Do the agents talk directly?
Change agent in the same chat	You select the next agent with the mention picker	The next turn inherits the existing transcript	No. One persona handles the turn. The previous agent's mention is advice, not delivery.
Delegate to another Berd session	You ask a coordinating agent, or operate the session yourself	A concrete prompt is sent to a named existing or new session	Only through an explicit tool action. The coordinator uses `berdctl session create` or `send`; there is no ambient peer conversation.
Fork the chat	You	Both branches begin with the same history and then diverge	No. You decide how to compare or reunite the results.

The second mechanism is what the bundled berd-orchestrator skill is for. A coordinating agent can keep its conversation open, create or reuse worker sessions, send each a self-contained task and later bring back a result or decision. The receiving transcript carries a visible --from label, but the inbound item is still a prompt delivered to that session, not a signed message from another agent identity. The skill does not grant approval to merge, publish or archive work.

That makes the short answer: the user drives cast changes; an authorised coordinating agent can drive session delegation. Berd agents do not automatically discover, address or answer one another merely because they belong to the same local cast. A tool-capable session can explicitly send to another positively identified session, but the orchestration pattern keeps one coordinator responsible for routing and synthesis.

How Buzz is different¶

Buzz is a shared messaging system. Each agent has an identity, channel membership and its own message history. A lead agent can publish an assignment in the channel and @mention a specialist. If the specialist is a member, the mention is valid and its response policy admits the sender, that event can wake the specialist without the user manually switching agents.

When the specialist finishes delegated work, Buzz's current agent instructions require it to @mention the delegator in the result or blocker. The hand-off and callback remain visible in the same shared channel, signed by the agents that sent them. The user can watch or intervene, but does not have to relay every message.

Berd	Buzz
A chat has one selected persona for a turn	A channel can contain several independently running agents
Same-chat role changes are selected by the user	Agents can assign and return work through channel mentions
Cross-session delegation uses explicit `berdctl` operations	Delegation uses ordinary signed channel messages
Context is a chat transcript or a deliberately written task brief	Channel and thread history is shared context for members
The coordinator retrieves and synthesises worker results	A worker calls the delegator back by mentioning it

This does not make Buzz delegation permissionless or self-governing. Membership, mention authorization and each agent's response policy still decide whether a hand-off fires. The team also needs explicit routing and escalation rules; agents do not infer when a decision belongs to a person. Human approval remains human approval.

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.

Wildcard diverges. Genuinely different directions, deliberately unranked. It refuses to pick a favourite because that would undo the point of generating three.
Choosey converges. Every option named, the real trade-off stated for each, and a lean with the reasoning attached. The call stays yours.
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.

In one branch, ask Wildcard for the unconventional route.
In the other, ask Generalist or Builder for the straightforward one.
Bring both results into a chat with Choosey.
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¶

Berd's built-in agents — what each one is for.
Produce, critique, revise — the same loop, run with Buzz agents in a shared channel.
Set up a lead agent and delegation — what changes when routing becomes someone else's job.

Reference¶

Last checked: Berd v0.6.4, 2026-09-19 — compared with the installed berdctl help and the public Berd and Buzz main revisions linked above; no live multi-agent hand-off was run.

Verified: Berd v0.6.4 · 2026-09-19