Set up a content review pipeline

Why this matters

Some agent output should never publish without a human glancing at it. Brand-voice replies. Blog drafts. Contract terms. Customer-facing emails to a high-stakes account. Anything where one wrong word costs reputation, money, or trust.

The pattern is called human-in-the-loop: the agent drafts. The human reviews. Only approved drafts go out. The trick is making the loop fast enough that you actually use it instead of bypassing it. Today, you build that. By the end, you’ve got a pipeline that gives you the speed of agent drafting with the safety of human approval, and a way to make the agent better every time you reject something.

Quick start

1. Sign in: open Auxot in your browser and log in.

2. Open chat with the Admin Agent: click Chat in the left menu, make sure the agent picker reads “Admin Agent.”

3. Describe the pipeline: paste this:

   I want a content review pipeline. Build a drafting agent for [what — e.g., "weekly customer newsletter," "outbound sales emails," or "blog drafts"]. Wire it into a workflow that drafts on demand or on a schedule, then pauses for my approval before anything goes out. When I approve, it publishes (or sends to me to publish). When I reject, it loops back for another pass with my feedback.
   

4. Answer the Admin Agent’s questions: what to call the drafting agent, where approvals should land (Slack, email, or chat), and what counts as “publish” (post to a channel, send an email, or just hand it back to you).

5. Confirm: the Admin Agent proposes the agent, the workflow, and the delivery wiring. Say “yes, set it up.”

Done? Trigger a draft. Approve or reject when the request lands. Watch the loop run.

The agent can do that?

A review pipeline is only as good as the loop. These three prompts turn it from a “yet another inbox” into something that actually saves you time and gets sharper over weeks.

1. Have the drafting agent attach its reasoning so review takes 30 seconds

Open chat with the drafting agent and ask:

When you produce a draft, attach a short note at the top: what you're trying to accomplish with this draft, what tradeoffs you made (e.g., "leaning warmer because the customer mentioned a personal milestone"), and anything you weren't sure about. Keep the note under 60 words. Make it easy for me to scan and decide approve/reject in 30 seconds.

Why it’s non-obvious: Review fatigue kills human-in-the-loop pipelines. If reviewing a draft takes five minutes, you start rubber-stamping. The reasoning note inverts that: you spend 20 seconds reading the agent’s intent, 10 seconds spot-checking whether the draft actually does that, and approve or reject. Reviewing 10 drafts a day stays sustainable instead of becoming a chore.

2. Have the Admin Agent learn from your rejections

After a few weeks of running the pipeline, head to chat with the Admin Agent:

Look at the drafts I've rejected from my "[drafting agent name]" over the last [N weeks]. What patterns are in the rejections? Update the agent's description and context files so the next batch of drafts doesn't make those same mistakes.

Why it’s non-obvious: Most people reject drafts and move on without analyzing the rejections. The Admin Agent reads the pattern: “you keep rejecting drafts that mention the competitor by name,” “you keep rejecting drafts that lead with the discount instead of the value”, and folds the lesson into the agent’s instructions. The pipeline gets less work for you over time, not more.

3. Build a “second-opinion” agent that reviews the first agent’s drafts before they hit your queue

Inverted-usage move. Once the drafting agent is solid, ask the Admin Agent:

Build me a "Draft Review" agent. Its job is to read drafts from my "[drafting agent name]" before they reach my approval queue, and either approve them silently (high confidence, send straight to me as 'pre-approved') or flag specific concerns I should look at first ('this paragraph contradicts our pricing policy,' 'tone is off for this audience'). Wire it into the workflow before the human approval step.

Why it’s non-obvious: A second agent isn’t redundant: it’s a quality gate. Drafts that are obviously fine get pre-approved silently; you spend your review budget only on the ones that need it. Pairs well with the power move 2 learning loop: as both agents improve, the share of “needs human eyes” drafts drops over months, not days.

Go deeper

Where human-in-the-loop helps and where it hurts

Human-in-the-loop is right when:

• The cost of a wrong output is high (legal, financial, brand-damaging).
• Your judgment is the bottleneck on quality, not speed.
• You can review fast (under a minute per item).

Human-in-the-loop is wrong when:

• The cost of a wrong output is low (a draft tweet that won’t post anyway).
• The agent’s judgment is already better than yours on this kind of work.
• The volume is so high that you’d rubber-stamp everything to keep up.

For high-volume work where rubber-stamping would happen, the answer isn’t “no review”: it’s sampled review: have the workflow auto-approve 90% and route 10% to you, randomly selected. You catch quality slipping without becoming the bottleneck.

The approval interface matters

Approvals can land in three places, ranked by speed:

1. Slack DM (Connect Slack to your agents): fastest. Click ✅ or ❌ in the message, optionally add a feedback comment. The workflow picks it up.
2. Email: slower, but works if you don’t live in Slack. Approve/reject links in the email.
3. Auxot chat thread: slowest, requires you to remember to check. Useful when the volume is low and you batch-review once a day.

Pick where your day actually happens. The wrong channel is the most common reason these pipelines die.

Social posts: route through Buffer

The pattern in the rest of this tutorial (agent drafts, human approves in Auxot, then publishes) does not apply to social posts. For LinkedIn, X, or Bluesky, the right wiring is Buffer’s official MCP (mcp.buffer.com/mcp). See Wire social posts through Buffer for the full wiring.

Buffer is a social-media scheduling tool with a built-in queue: posts wait in the queue until you approve them or until the scheduled time arrives. That queue IS the review gate this tutorial usually builds inside Auxot. You don’t add a second review step in Auxot; Buffer’s review is enough.

The Auxot wiring shape is shorter:

1. The drafting agent reads source material (blog, news, doc).
2. The agent calls Buffer’s create_update tool with the post text and a future schedule time.
3. You open Buffer, review the queue, edit or approve. The post goes live at the scheduled time.

Buffer’s free tier covers three channels with ten scheduled posts each.

Avoid these paths:

• Direct LinkedIn posting. No official LinkedIn MCP exists for posting on a user’s behalf in May 2026. Community MCPs hit the limited LinkedIn API and most useful endpoints require partner approval the average user won’t have.
• Direct X (Twitter) posting. Requires X’s Basic API tier ($100/month minimum) to post via the official API. Not viable for the general audience.
• LinkedIn DMs or connection requests via agent. No path exists. Skip from scope.

If the use case is “agent posts to my Bluesky” specifically and you want minimal infrastructure, a Bluesky community MCP is the only direct-platform option worth wiring outside Buffer (Bluesky is free and open; LinkedIn and X are not).

Email drafts: route through draft-only MCPs

If “publish” means an outbound email (newsletter, customer reply, sales follow-up), the agent drafts and lands the message in your Drafts folder. You send from there. The Drafts folder is the structural review gate, same idea as Buffer’s queue for social.

For Gmail, see Wire Gmail drafts through Google’s official MCP. Google’s official Gmail MCP is free and draft-only by design (no send scope in OAuth).

For Outlook, see Lock Outlook drafts via a draft-only tool policy. Composio Outlook exposes both draft and send tools, so the tool policy is the load-bearing lock that keeps the agent from sending.

The cross-cutting principle (why the agent should never have a send tool, regardless of MCP) lives in Keep send_email out of your agent tool policies.

The rejection loop

When you reject a draft, two things should happen:

1. The workflow loops back to the drafting agent with your feedback (“too formal, customer mentioned their kid’s birthday: warm it up”).
2. The agent produces a new draft incorporating the feedback, which lands back in your queue.

If the workflow doesn’t auto-loop and instead just stops on rejection, you’ll abandon the pipeline. The Admin Agent should set this up by default; if it doesn’t, ask explicitly: “Make sure the rejection loops back to the drafting agent with my comment, not just kills the run.”

Troubleshooting

• The agent’s drafts feel generic. Its description and context files don’t have enough about your voice and audience. See Give your agent its job description.
• You’re rejecting more than you approve. Either the agent’s description is wrong (see Give your agent its job description), or the kind of work doesn’t suit human-in-the-loop (the agent can’t get close enough to your voice without a human writing it from scratch). Try smaller scope: instead of “draft a full newsletter,” “draft three subject lines I can pick from.”
• The approval requests pile up and you never get to them. Move the approval channel (see “approval interface matters”), or accept that this kind of work isn’t pipeline-able for you and do it manually. A pipeline you don’t use is worse than no pipeline.
• The same kind of edit keeps happening. That’s power move 2 territory: feed the rejection patterns back into the agent’s description.

Variations & edge cases

• Free tier: human-in-the-loop pipelines work at all tiers. Multi-step workflows with conditionals (the rejection loop) need the workflow features in Run a workflow.
• Multiple reviewers: if more than one person needs to approve (e.g., legal review + brand review), chain two approval steps in the workflow. Each approver gets their own channel and their own feedback path.
• Auto-publish vs hand-back: “publish” doesn’t have to mean the workflow sends the email itself. For high-stakes content, “publish” can just mean “approved draft drops into my drafts folder and I send it manually.” Same loop, lower automation risk.
• Be selective about adding review. It’s tempting to add a review step to every agent. Resist. Reserve human-in-the-loop for output where the stakes match the cost of your attention.

Walkthrough

Step 1: Open chat with the Admin Agent

Click Chat in the left menu. Make sure the agent picker at the top reads “Admin Agent.”

Step 2: Describe the pipeline

Paste something concrete:

I want a content review pipeline. Build a drafting agent for our weekly customer newsletter — it should pull in the past week's product updates, customer wins, and any blog posts, and turn them into a draft newsletter in our brand voice. Wire it into a workflow that runs every Friday at noon, drops the draft into my Slack DMs for approval, and either publishes (sends via our newsletter tool) or loops back if I reject. Make sure rejections loop back with my feedback, not just stop.

The more specific you are about what counts as publish, where approvals land, and what should happen on rejection, the less back-and-forth.

Step 3: Answer the Admin Agent’s questions

Common decisions:

• What to call the drafting agent. Something specific: “Newsletter Drafts,” “Outbound Email Drafts.” Name the work, not the role.
• Approval channel. Slack (fastest), email, or chat thread.
• Approval format. ✅/❌ buttons (fastest), reply with “yes” / “no, [feedback]” (more flexible).
• What “publish” means. Send the actual email? Drop into a drafts folder for you to send? Post to a public channel? Different downstream wiring.

Step 4: Confirm and let the Admin Agent set it up

The Admin Agent proposes:

• A drafting agent with the right description and context files (Give your agent its job description).
• A workflow (Run a workflow) that runs the agent, pauses for approval, and either publishes or loops back.
• The delivery integration (Connect Slack to your agents if Slack, otherwise email or chat).

Read the proposal carefully. Push back on anything that’s wrong: “Make the rejection loop pass my feedback to the agent, don’t just restart with a blank prompt,” “Approval should be in Slack DM, not the public channel.”

Step 5: Test the loop end-to-end

Trigger the workflow manually (don’t wait for the schedule). The drafting agent runs. The approval request lands wherever you set it.

Three things to verify:

1. Reject once with feedback. Confirm the workflow loops back, the agent produces a new draft, and the new draft incorporates your feedback.
2. Approve once. Confirm the “publish” action actually happens: email sends, Slack post lands, draft drops into the right folder.
3. Read the reasoning note. If you set up power move 1, the agent should attach a short note explaining its choices. If it didn’t, ask: “Add the reasoning note to every draft going forward.”

Step 6: Let it run for a few weeks, then iterate

The first month is data. After 3-4 weeks, run power move 2: have the Admin Agent analyze your rejections and tighten the agent’s description. After 6-8 weeks, consider power move 3: add the second-opinion agent if review is taking too much time.

Pipelines don’t ship done. They get sharper as the agent learns what you actually want.

What’s next

• → Adapt content for new locales or audiences with human review. Same review spine: adapted copy + glossary receipts + claim checks before anything ships cross-locale.
• → Triage and follow up on inbound leads. Same draft-and-review muscle on the funnel: score, reply, and follow up before opportunities cool.
• → Enforce a living style guide and terminology. Mechanical voice pass before approval: violations table tied to glossary lines, fewer hyphen wars in review.
• → Give your agent its job description. The drafting agent’s voice depends almost entirely on its description; tighten it as you learn.
• → Run a workflow. The pause-for-approval and rejection-loop logic lives in the workflow.
• → Run a deal desk for pricing and legal exceptions. Same human-in-the-loop spine: commercial exception packets for finance/legal instead of marketing drafts.
• → Connect Slack to your agents. Slack DM approvals are the fastest review interface for most people.
• → Wire social posts through Buffer. The canonical wiring when the output is a LinkedIn, X, or Bluesky post.
• → Wire Gmail drafts through Google’s official MCP. The canonical wiring when the output is an outbound Gmail message.
• → Lock Outlook drafts via a draft-only tool policy. The canonical wiring when the output is an outbound Outlook message.
• → Keep send_email out of your agent tool policies. The structural argument for why the drafting agent should never have a send tool.
• → Build your customer support agents. Same multi-agent thinking applied to a different problem.

Reference

• Human-in-the-loop pattern: agent drafts → human approves or rejects → approved publishes, rejected loops back with feedback.
• 30-second review goal: any longer and you’ll rubber-stamp. power move 1’s reasoning note is how you keep it short.
• Approval channels by speed: Slack DM > email > chat thread. Pick where your day actually happens.
• Sampled review is the answer for high-volume work where 100% review would mean rubber-stamping. Auto-approve most, route a random subset to you.
• Be selective about adding review: the pipeline costs your attention. Reserve it for output where stakes match.
• See also: Build your customer support agents, Triage and follow up on inbound leads, Create an agent from scratch, Run a workflow, Connect Slack to your agents.