Anyone can spin up an agent in Clarify - tell Rep what you want, and it wires up the trigger, writes the instructions, and picks the tools. Most of the time, that's all you need.

But the agents people actually keep running - the ones that quietly update the CRM after every call, or land a ready-to-send draft in your inbox before you've finished your coffee - share a handful of traits. They're narrowly scoped. They know exactly when to fire. And their instructions read less like a wish and more like a runbook.

This guide is the craft behind those agents: how to design a trigger, how to write instructions an agent can actually follow, and the small decisions that separate "neat demo" from "I'd be lost without it."

New to agents? Start with Agents for the basics - what they are, what they cost, and how to share them. This guide goes a level deeper.

Every agent is three things working together:

Get all three pulling in the same direction and the agent feels like a teammate. Get one wrong and it either never fires, does the wrong thing, or quietly burns credits. The rest of this guide is about getting each one right.

Three quick checks save a lot of frustration.

Is it a one-off, or something you'll want again and again? If you just need the work done once - clean up this list, draft this one email, pull these numbers - don't build an agent. Ask Rep to do it right now. Agents earn their keep by running repeatedly on their own; a one-time task doesn't need one.

Does it need to run on its own, and does it involve judgment? That's the sweet spot for an agent - anything that fires on an event and requires a bit of reasoning. "Classify each meeting as discovery, demo, or negotiation." "Draft a reply in my voice." "Update the deal based on what was said." All great agent work.

Are you just trying to keep a tidy collection of records? Then you don't need an agent - you need a dynamic list. "Every open deal over $50k" or "every contact we haven't touched in 90 days" is a list that updates itself, for free, no reasoning required. Reach for an agent only when something has to happen to those records.

The trigger decides when your agent runs - and, just as importantly, when it doesn't. This is where most agents are won or lost, because every run costs credits and an agent that fires on everything gets expensive and noisy fast.

Here's the single most useful habit: narrow the trigger with a filter, instead of telling the agent to check things once it's already running.

Say you want an agent that drafts replies to emails sent to you. You could write "only draft if the email was actually sent to me" in the instructions - but by then the agent has already woken up, read the thread, and spent credits, just to decide it shouldn't have bothered. A trigger filter (recipient contains your email) stops the run before it starts. Cheaper, faster, quieter.

Rule of thumb: if you can express the condition as a property of the triggering event, make it a filter. Save the instructions for judgment the filter can't make.

Update triggers can fire on any change to a record, only when a specific field changes, or only when a field changes to a particular value. "When a deal's stage changes" is different from "when a deal's stage changes to Closed Won." The more specific you are, the fewer wasted runs.

This is the heart of it. Tools decide what an agent can do; instructions decide what it should do. The best instructions in Clarify read like a careful runbook written for a brand-new hire who's eager, capable, and extremely literal.

Seven habits show up in every great one.

Start with a single sentence that names what the agent is and the one thing it does. "You are a post-meeting CRM updater. When a meeting transcript is ready, update the deal, company, and people linked to that meeting to reflect what was actually said." Everything after that is detail in service of that one job.

Before the agent does anything useful, make it earn the right to act. The strongest agents lead with a checklist of conditions, applied in order, that stops the moment one fails:

Scope, apply in order; stop as soon as one fails:

- Act only on the meeting that triggered this run, and only on the records linked to it.
- Act only on meetings the user actually attended.
- Skip internal-only meetings.

This is your cost control and your trust control. An agent that knows exactly when to walk away is an agent you'll leave running.

Tell the agent to check the current state before it changes anything. Read the existing field value - if your new value matches what's there, skip it; never make a no-op or cosmetic change. Never overwrite a value a human already set with a weaker guess. "If the correct value is ambiguous, leave the field as it is" is a line worth borrowing verbatim.

Great instructions spend real estate on the negative space. Don't draft for mail that's only CC'd to you. Don't infer a deal stage from tone. Don't invent next steps that weren't agreed. And give the agent a clear default for uncertainty - almost always, when in doubt, do nothing. As one of our drafting agents puts it: "A missed draft is harmless; a draft for mail that wasn't theirs erodes trust."

Vague instructions produce vague behavior. "Update the deal" invites guessing; "change the deal stage only when the transcript explicitly signals movement - a verbal commitment, a signed agreement, a clear loss - never from tone or the absence of news" gives the agent a bright line. Name the fields. Name the conditions. Name the values that are off-limits.

Write what you want to happen - "look up the linked person," "post a summary to the channel," "leave the reply in my drafts" - never the name of a tool or a button. You pick the tools separately (next section). Naming them in the instructions just dates the agent and trips it up. Keep instructions about intent; let the toolset handle capability.

One agent, one job. The post-meeting follow-up agent drafts the email and only the email. The post-meeting CRM agent updates records and only records. Both can fire on the same meeting without stepping on each other - because each one's instructions explicitly say "this is mine, that's the other agent's." Small, single-purpose agents are easier to trust, test, and fix than one sprawling do-everything agent.

Bonus: format for the human. If your agent's output is for you - a digest, an alert, a summary - tell it how to make that output skimmable. Lead with a one-line count. One bullet per item. Make records clickable. A daily recap nobody reads is just credits on fire.

If you find yourself writing the same chunk of instructions across several agents - your qualification criteria, your email style guide, your account-tiering rules - pull it into a Skill and reference it from each agent. Write it once, improve it once, and every agent that links it gets better at the same time.

Tools are an allowlist: the agent can only use what you give it, and nothing else. Two decisions matter.

What can it touch? Grant the minimum. A drafting agent needs to read records and create a draft - it doesn't need to update deals or send mail. Smaller toolsets mean fewer ways to go sideways.

Can it act on its own, or should it ask? Each tool you grant can run automatically or require your approval. Reading data? Let it run - read-only tools are safe on automatic. Writing records, sending email, posting to Slack? That's your call. While you're learning an agent's behavior, set the writes to needs approval and you'll get a heads-up before anything happens - approve or deny in-app, no need to re-run the whole thing. Once you trust it, flip the writes to automatic.

One subtlety that catches people out: live data and history are different tools. Reading the CRM tells you what's true right now - current stage, open deals, this week's pipeline. It can't tell you what changed. For "which deals moved to a later stage this week" or "how long has this sat in negotiation," the agent needs the analytics event log, which records every change over time. If your agent reasons about trends or transitions, make sure it has both.

If your agent produces something you need to see - a pipeline review, a daily wrap-up, an alert - decide where it lands. Clarify agents deliver to two places:

That's the full list. And if the agent just quietly updates CRM fields, it doesn't need a delivery channel at all - the work is the output.

Don't build an agent and walk away - an agent Rep builds is enabled the moment it's created and will run the next time its trigger fires. So review the trigger, instructions, and tools before that happens, and toggle it off if you'd rather hold. Either way, run a test first: use the Run agent button inside the agent to kick off a run outside its normal trigger. Pick a realistic scenario - a real recent meeting you attended, a real deal, a real thread - and watch what it does.

There's no undo for agent actions - if an agent writes something wrong, you ask Rep to revert that specific change. That's exactly why approval mode on the writes is worth it while you're still learning an agent: it pauses before each action so nothing happens you didn't okay.

When something looks off, resist the urge to immediately rewrite the instructions. Open the run and read the activity log of what the agent actually did. Nine times out of ten the fix is targeted - a missing filter, a fuzzy condition, one field it shouldn't have touched - not a from-scratch rewrite. Diagnose, adjust, re-run.

Every run spends credits based on the actual work done - a quick field update is cheap; a deep research pass is not. A few habits keep the bill sane:

Every agent also has a hard system ceiling of 100 runs per hour, but treat that as a backstop, not a tuning knob - your run limit, filters, schedule, and approval mode are what actually keep usage in check.

The fastest way to learn the craft is to read agents that already nail it. Each of these is a small masterclass in the habits above - and all four ship as templates you can install in a couple of clicks from the new-agent gallery.

Fires when a new inbound email addressed to you arrives.
​Does read the full thread and linked CRM context, then leave a reply in your voice - as a draft, never sent.

Why it's good: it's a textbook gate-first agent. The very first thing it does is check the recipient - your personal address has to be in the To field, not a shared alias, not just a CC - and if that fails, it does nothing. It grounds the reply in real context (a generic reply is "worse than none") and never sends on your behalf. The guiding principle, stated outright: a missed draft is harmless; a wrong one erodes trust.

Fires when a meeting transcript becomes available (the two-trigger pattern: create and update).
​Does update the deal, company, and people linked to that meeting from what was actually said.

Why it's good: it's the gold standard for read-before-write and staying in its lane. It only touches records linked to the triggering meeting - never the wider database. It moves a deal stage only on an explicit signal in the transcript, never on tone. It reads each field first and skips no-op writes. It leaves human-set values alone. And it ends with a one-line summary comment so you can see exactly what changed - then explicitly hands the email follow-up to a different agent.

Fires when a meeting transcript becomes available.
​Does draft a follow-up email to the attendees, grounded in the transcript and the next steps you agreed.

Why it's good: it's the perfect counterpart to the CRM agent - same trigger, opposite lane. It drafts the email and changes nothing in the CRM. It addresses recipients from the meeting's actual participants (not a fuzzy name search that could grab the wrong person), checks for an existing draft before writing a new one, and only acts on meetings you actually attended. Two agents, one meeting, zero collisions - because each one's instructions say exactly where its job ends.

Fires at 5pm, Monday to Friday (a recurring schedule).
​Does email you one skimmable recap - today's meetings, emails still awaiting a reply, tasks done, tasks due - so nothing slips.

Why it's good: it's a masterclass in formatting for the human. It opens with a one-line count ("3 meetings today, 2 emails awaiting a reply, 4 tasks done, 1 due tomorrow"), groups everything under short headings, keeps each item to a line, and makes every meeting and deal clickable. It skips empty sections instead of printing hollow headings, and it never invents an item to fill space. One email a day, built for a ten-second skim.

Want to build one of these? Just tell Rep what you're after - "draft replies to emails sent to me" - and it'll set up the trigger, write the first draft of the instructions, and pick the tools. Then bring it back here and make it great.