Human-in-the-Loop AI Content Workflow

A human-in-the-loop AI content workflow for teams running many agents

Once a team runs more than one agent, the question stops being "can AI write this" and becomes "which agent wrote this, who approved it, and how do we stop it." SocialHandoff gives every agent its own scoped key, checks every draft against guardrails, and records every action in a hash-chained audit log.

How to do it

One key per agent Each agent gets a key scoped to specific networks and permissions: draft, schedule, analytics. No agent can approve its own draft.

Guardrails before review Banned topics, per-network length, alt text, daily limits, and blocked link shorteners are checked on every draft.

Trust ladder Agents start draft-only. Promote them by hand or by policy with autoPromote after clean approvals; a guardrail failure demotes at once.

Policy as code The trust policy lives in .socialhandoff/policy.json in your repo, reviewed like any other change and applied with pnpm socialhandoff policy apply.

Verify the record The audit log is append-only and hash-chained, and GET /v1/audit/verify confirms it has not been altered.

Scenario: a research crew in CrewAI drafts 12 LinkedIn posts from industry reports each week. Its key allows draft on LinkedIn only. One draft quotes a competitor by name, which is a banned topic; it fails the guardrail and never reaches review. The other 11 go to the inbox, where an editor approves 9.

Governance for agent-written content

The more agents you run, the more you need the controls you would expect for any automated system with access to production: least privilege, validation, promotion based on track record, an emergency stop, and a tamper-evident log. SocialHandoff provides those controls for social publishing. See human-in-the-loop and least privilege for the concepts.

Connecting your agents

Framework agents connect over the REST API or MCP: CrewAI, LangChain, OpenAI Agents SDK.
Keys are created per agent; see agent keys and permissions. Keys are stored as SHA-256 hashes.
Write the trust policy in your repo and review it like code. See trust ladder.

Permission design

Split responsibilities across agents. A research agent drafts. A planner schedules. A reporting agent reads analytics. None of them approve; only owner keys can. When one agent misbehaves, you revoke or demote that one key without touching the others.

Prompt injection and bad sources

Agents that read the web or documents can be steered by hostile text. See prompt injection. Guardrails catch the obvious failures, human approval catches the subtle ones, and the kill switch stops everything if you see a pattern you do not like.

Measuring agent quality

Approval rate per agent is the most useful metric you have: the audit log shows how many drafts each key produced, how many were approved, edited, or rejected. Track it over time before promoting any agent. Per-post metrics then tell you whether approved posts performed.

Pitfalls

Shared keys. You lose attribution and cannot demote one agent.
Promoting too early. Wait for a real record, not a good week.
No audit review. Check the audit log regularly, not only after an incident.

Frequently asked questions

Can an agent approve its own posts?

No. Approval is only available to owner keys, and no agent can approve a draft it created.

How do we know which agent wrote a post?

Every agent has its own key, and the audit log records the key that drafted each post and the person who approved it.

Can the trust policy be reviewed like code?

Yes. It lives in .socialhandoff/policy.json in your repository and is applied with pnpm socialhandoff policy apply, so changes go through your normal review.

What stops a runaway agent?

Per-account daily limits cap volume, guardrail failures demote the agent, and the kill switch pauses all agents and holds queued posts.