How do I set up a multi-agent management platform for state persistence and human-in-the-loop approvals?

Here’s a practical way to set up a multi-agent management platform with state persistence and human-in-the-loop (HITL) approvals.

1) Define the core architecture

You usually want these components:

• Orchestrator / Supervisor
  • Coordinates agents
  • Decides which agent acts next
  • Maintains workflow state
• Specialized agents
  • e.g. Research, Planner, Executor, Reviewer, Compliance
• Persistent state store
  • Saves conversation/task state, agent outputs, approval status, and checkpoints
• Approval gateway
  • Pauses execution when a human decision is required
• Event bus / queue
  • Helps agents communicate asynchronously
• Audit log
  • Tracks every action, message, tool call, and approval

A good pattern is:

User request → Orchestrator → Agents → State store → Approval checkpoint → Human approval/rejection → Resume

---

2) Choose a state model

Persist everything needed to resume execution safely.

Typical state fields:

• workflow_id
• run_id
• current_step
• active_agent
• task_description
• agent_messages
• tool_calls
• artifacts
• approval_required: true/false
• approval_status: pending/approved/rejected
• approval_reason
• timestamps
• retry_count
• final_result

Store state in one of:

• PostgreSQL for structured workflows and auditability
• Redis for fast ephemeral state
• MongoDB / document store for flexible agent transcripts
• Object storage for larger artifacts

A common setup:

• PostgreSQL for workflow metadata and approvals
• Redis for runtime/session state
• S3/blob storage for files and large outputs

---

3) Make agents stateless, state lives outside them

This is important for reliability.

Each agent should:

• Read the current state from the store
• Perform its role
• Emit result + next-step suggestion
• Write updates back to the store

Avoid relying on in-memory state inside an agent process, because:

• processes can crash
• you may scale horizontally
• you need resumability

---

4) Implement workflow checkpoints

A checkpoint is a save point before risky or human-sensitive actions.

Example checkpoints:

• Sending an email
• Making a purchase
• Modifying production data
• Deploying code
• Releasing a report to a customer

At a checkpoint:

1. Agent prepares proposed action
2. Orchestrator stores it
3. Approval gateway flags it as pending
4. Human reviews in UI
5. Human approves/rejects
6. Workflow resumes or branches

---

5) Build a human approval interface

Your UI should show:

• Current workflow status
• Agent reasoning summary
• Proposed action
• Supporting evidence/artifacts
• Approve / Reject / Edit / Request changes buttons
• Comments field
• History of prior approvals

For safety and traceability:

• Include who approved
• When they approved
• What exactly was approved
• A diff if the human modified the action

---

6) Use a message/event-driven flow

Instead of direct synchronous calls between agents, use events such as:

• task.created
• agent.completed
• approval.requested
• approval.granted
• approval.denied
• workflow.resumed

This makes it easier to:

• retry failed steps
• scale agents independently
• monitor execution
• replay workflows

Tools often used:

• RabbitMQ
• Kafka
• Celery / Redis queue
• AWS SQS/SNS
• Temporal for durable workflows

---

7) Recommended control logic

A simple orchestration loop:

1. Receive user request
2. Create workflow state
3. Assign first agent
4. Agent completes work
5. Orchestrator checks if approval is needed
6. If yes, pause and notify human
7. Wait for decision
8. If approved, continue with next agent/action
9. If rejected, revise or terminate
10. Persist final outcome

Pseudo-logic:

if state.approval_required and state.approval_status == "pending":
    pause_workflow()
elif approval_received:
    resume_workflow()
else:
    route_to_next_agent()

---

8) Add guardrails

For production systems, include:

• Role-based access control
• Approval thresholds based on risk or cost
• Prompt/tool input validation
• Action allowlists
• Rate limits
• Secrets management
• Full audit trail
• Fallback/rollback strategies

Examples:

• Require 2 approvals for spend > $1,000
• Block production DB writes without manual confirmation
• Prevent agents from accessing secrets directly

---

9) Persist conversations and artifacts

Store:

• full chat history
• agent outputs
• prompt versions
• model versions
• tool inputs/outputs
• generated files
• approval records

This helps with:

• debugging
• compliance
• reproducibility
• evaluation

---

10) A practical technology stack

One example stack:

• Backend: Python + FastAPI
• Workflow engine: Temporal or Celery
• DB: PostgreSQL
• Cache/session state: Redis
• Artifacts: S3
• Frontend: React/Next.js
• Auth: OAuth2 / SSO
• Logging/monitoring: OpenTelemetry + Grafana + Loki
• Agent framework: LangGraph, AutoGen, CrewAI, or custom

If you want durable orchestration and HITL, Temporal is especially strong.

---

11) Example data model

{
  "workflow_id": "wf_123",
  "status": "waiting_for_approval",
  "current_step": "send_email",
  "active_agent": "executor",
  "task": "Draft and send outreach email",
  "approval_required": true,
  "approval_status": "pending",
  "proposed_action": {
    "type": "send_email",
    "recipient": "client@example.com",
    "subject": "Follow-up",
    "body": "..."
  },
  "history": [
    {
      "step": "research",
      "agent": "researcher",
      "output": "..."
    }
  ]
}

---

12) Minimal implementation pattern

If you’re building from scratch:

• Orchestrator stores workflow state in PostgreSQL
• Agents are worker services that fetch tasks
• Before risky operations, write an approval request record
• UI polls or subscribes to approval events
• On human approval, orchestrator updates state and enqueues the next task

---

13) Best practice: separate “thinking” from “acting”

A strong pattern is:

• Planner agent: decides what should happen
• Executor agent: prepares the action
• Reviewer agent: checks for issues
• Human approver: authorizes real-world effects

This reduces the chance that one agent directly performs unsafe actions.

---

If you want, I can also give you:

1. a reference architecture diagram,
2. a PostgreSQL schema for workflow persistence and approvals, or
3. a FastAPI + Temporal example for implementing this.