Why agent design matters
Agents in Coworker run autonomously — on a schedule, in response to events, or when called directly. That power comes with responsibility: a poorly designed agent can flood a Slack channel with duplicate messages, produce vague outputs that require manual interpretation, or silently fail to complete the task it was built for.
This article covers the best practices for building agents that behave predictably, produce useful outputs, and stay within the bounds you intend.
Write precise, complete instructions
Your agent's system prompt is its rulebook. Vague instructions produce vague results.
Do:
Clearly define the task: what to look for, what data to use, and what to do with it
Specify the output format — a bulleted Slack message, a structured report, an email summary
Set explicit boundaries: what the agent should not do (e.g., "Do not send a message if there are no new items to report")
Use concrete filters: date ranges, deal stages, specific channels, named individuals
Avoid:
Open-ended instructions like "summarize everything" — scope the data explicitly
Assuming the agent will infer context it was never given
Combining multiple unrelated tasks in one agent — split them into separate agents
Tip: The more detailed your instructions, the more reliably your agent will behave. You can always edit and refine later.
Only grant the tools your agent needs
Each tool you enable expands what your agent can read or write. Excess tool access increases the chance the agent acts on unintended data or performs unintended actions.
Give the agent access only to the specific data sources relevant to its task (e.g., HubSpot for a deal-monitoring agent, Slack for a channel-digest agent)
If an agent only needs to read data, do not enable write tools
Review tool access when duplicating or repurposing an existing agent — inherited permissions are easy to miss
Choose the right trigger — and scope it carefully
How and when your agent fires determines how much noise it creates. A trigger that is too broad will result in an agent running more often than intended.
Scheduled agents:
Match the schedule to the data freshness — a daily digest doesn't need to run hourly
Avoid scheduling write-heavy agents during peak hours for your team
Slack message triggers:
Narrow the trigger using both a specific channel and a text string where possible — listening to a broad channel without a keyword filter will fire your agent on nearly every message
Use the user filter to limit which senders activate the agent
Custom event triggers:
Write conditions that are unambiguous — the more specific the condition, the more reliably the agent fires only when intended (e.g., "A new HubSpot lead has been submitted with company size greater than 50" rather than "A new lead arrives")
Meeting event triggers:
Specify the exact meeting you want the agent to follow up on — without scoping, the agent may run after every meeting you attend
Use first-person references ("my meetings") rather than naming yourself explicitly to ensure the trigger scopes correctly to your calendar
Note: Coworker prevents concurrent duplicate executions — if an agent is already running, a new trigger will not start a second run at the same time. However, back-to-back runs on frequent schedules can still produce repeated outputs if your instructions don't account for "nothing new to report" scenarios.
Prevent spam and duplicate outputs
The most common agent issue is outputs that repeat unnecessarily. Here's how to design against it:
Add a "nothing to report" condition: Explicitly instruct the agent to send nothing (or a brief acknowledgment) when the data doesn't meet the threshold for action. Example: "Only send a Slack message if there are 3 or more stale deals. If none qualify, do not send anything."
Scope the lookback window: For scheduled agents, define a clear time window for the data it should consider (e.g., "Look at deals updated in the last 7 days"). Without this, an agent may surface the same records every run.
Route outputs intentionally: If your agent outputs to Slack and also sends email, recipients may receive the same information twice. Choose one primary channel per agent, or use the "Notify only" mode for secondary destinations so teammates receive a lightweight ping rather than full duplicate output.
Use the API trigger's idempotency key: When triggering agents programmatically, include an
idempotencyKeyin your API call. This prevents the same event from accidentally triggering duplicate runs.Separate agent outputs from meeting summaries: Agent outputs and meeting summaries both arrive from Coworker — route agent outputs to a dedicated Slack channel or email label so they don't get buried alongside notetaker summaries.
Make complex agents reliable
Agents that handle multi-step workflows — pulling from multiple sources, making decisions, and writing outputs — are more likely to fail silently if they aren't designed carefully.
Break large workflows into smaller agents: A single agent that reads from five tools, makes three decisions, and sends two outputs is hard to debug. Consider splitting into a research agent (reads data, surfaces insights) and an action agent (acts on those insights).
Use Skills for reusable logic: If multiple agents share common instructions — for example, a standard way to format deal summaries — extract those into a Skill. Attach the Skill to each agent so changes propagate consistently rather than requiring edits in multiple places.
Use Action Queue for write-heavy tasks: When your agent performs write actions (creating Jira tickets, sending emails, updating CRM records), configure the output destination to route through the Action Queue. This places a draft card in front of a human before anything executes — useful for high-stakes or irreversible actions.
Test before scheduling: Run your agent manually before enabling a schedule or event trigger. Review the full output and confirm it handles edge cases — particularly the "nothing to report" scenario — before letting it run autonomously.
Start with a less frequent schedule: When launching a new scheduled agent, start with a daily or weekly cadence. Tune down to hourly only once you've confirmed the outputs are accurate and non-repetitive.
Agent design checklist
Before saving and enabling your agent, run through these questions:
Does my system prompt specify exactly what data to use and what output format to produce?
Have I included a condition for when the agent should not send output?
Is the tool access limited to only what this agent needs?
Is my trigger scoped to avoid firing on unintended events?
Have I tested the agent manually and reviewed its output?
Is the output destination (Slack, email, Action Queue) appropriate for the sensitivity of the action?