The triage_ticket function from last week used one agent with one system prompt to produce one structured result. What if the communication goal isn't classification — it's tone?
Like rewriting the same draft email two ways — one for the exec and one for the team channel? I'd have to send it to the model twice with different instructions.
Exactly right. Two calls, two system prompts, two outputs. The trick is that each Agent instance carries its own persona — they don't share state:
def compare_tones(text: str) -> dict:
formal = Agent(model, system_prompt="Rewrite in a formal professional tone.")
casual = Agent(model, system_prompt="Rewrite in a casual friendly tone.")
return {
"formal": formal.run_sync(text).output,
"casual": casual.run_sync(text).output,
}
Do I need to worry about the two agents interfering with each other? Like, does one affect the other's context?
No shared state at all. Each Agent(model, system_prompt=...) is a fresh call — same model, different instruction layer on top. Think of them as two separate contractors given the same brief but different style guides. One writes a board memo; one writes a Slack message:
formal = Agent(model, system_prompt="Rewrite in a formal professional tone.")
casual = Agent(model, system_prompt="Rewrite in a casual friendly tone.")
I'm chaining these like functions now — I can pass the formal output into another agent, or pick whichever one scores higher on readability.
That's the right mental model. A dict return makes it easy to slot into a UI, a review tool, or an A/B test. The caller decides which version to use; the function's job is just to produce both.
We send two versions of every client email anyway — one that the lawyer approves and one that actually sounds human. Now that's a function I can call from a script.
And you've replaced a thirty-minute back-and-forth with a two-second function. Next step: batch this across every draft in the queue.
A system_prompt is an instruction layer that sits above the user message. Changing it is how you change the persona — the model is the same, the behaviour is different.
Why two Agent instances? Each instance holds its own system_prompt. Sharing one agent and changing the prompt between calls works too, but two named instances make intent obvious: formal and casual read like variables, not magic strings.
Return a dict, not a tuple. A dict key (result["formal"]) is self-documenting. A tuple index (result[0]) requires context to decode.
Do not call .output before .run_sync() completes — the call is synchronous so this is just sequencing: agent.run_sync(text).output, not agent.output on its own (that attribute does not exist on the Agent object itself).
The triage_ticket function from last week used one agent with one system prompt to produce one structured result. What if the communication goal isn't classification — it's tone?
Like rewriting the same draft email two ways — one for the exec and one for the team channel? I'd have to send it to the model twice with different instructions.
Exactly right. Two calls, two system prompts, two outputs. The trick is that each Agent instance carries its own persona — they don't share state:
def compare_tones(text: str) -> dict:
formal = Agent(model, system_prompt="Rewrite in a formal professional tone.")
casual = Agent(model, system_prompt="Rewrite in a casual friendly tone.")
return {
"formal": formal.run_sync(text).output,
"casual": casual.run_sync(text).output,
}Do I need to worry about the two agents interfering with each other? Like, does one affect the other's context?
No shared state at all. Each Agent(model, system_prompt=...) is a fresh call — same model, different instruction layer on top. Think of them as two separate contractors given the same brief but different style guides. One writes a board memo; one writes a Slack message:
formal = Agent(model, system_prompt="Rewrite in a formal professional tone.")
casual = Agent(model, system_prompt="Rewrite in a casual friendly tone.")I'm chaining these like functions now — I can pass the formal output into another agent, or pick whichever one scores higher on readability.
That's the right mental model. A dict return makes it easy to slot into a UI, a review tool, or an A/B test. The caller decides which version to use; the function's job is just to produce both.
We send two versions of every client email anyway — one that the lawyer approves and one that actually sounds human. Now that's a function I can call from a script.
And you've replaced a thirty-minute back-and-forth with a two-second function. Next step: batch this across every draft in the queue.
A system_prompt is an instruction layer that sits above the user message. Changing it is how you change the persona — the model is the same, the behaviour is different.
Why two Agent instances? Each instance holds its own system_prompt. Sharing one agent and changing the prompt between calls works too, but two named instances make intent obvious: formal and casual read like variables, not magic strings.
Return a dict, not a tuple. A dict key (result["formal"]) is self-documenting. A tuple index (result[0]) requires context to decode.
Do not call .output before .run_sync() completes — the call is synchronous so this is just sequencing: agent.run_sync(text).output, not agent.output on its own (that attribute does not exist on the Agent object itself).
Create a free account to get started. Paid plans unlock all tracks.