ONTO vs AutoGen: Human-in-the-Loop, Done Right

AutoGen pioneered the conversational multi-agent paradigm — agents talking to each other and to humans through a chat interface. Its UserProxyAgent pattern made human-in-the-loop a first-class concept in 2023, before most other frameworks had a real story for it.

ONTO and AutoGen both take human-in-the-loop seriously. They take it differently. This post compares the approaches.

How AutoGen does human-in-the-loop

The central abstraction is UserProxyAgent — an agent that represents the human. In a multi-agent conversation, the UserProxyAgent can be configured to prompt the human at certain steps. The agents around it can ask it for input, treat it as a tool, or hand control to it.

# Conceptual AutoGen pattern
user_proxy = UserProxyAgent(name="user", human_input_mode="ALWAYS")
assistant = AssistantAgent(name="assistant", llm_config=...)
user_proxy.initiate_chat(assistant, message="Plan a trip to Lyon")
# AutoGen runs the conversation, prompting the human via user_proxy.

This is conversationally elegant. The human is “in” the conversation, not “outside” it. The pattern fits well when collaboration with the human is iterative and frequent.

How ONTO does human-in-the-loop

ONTO uses Plan Mode + Execute Mode. Plan runs produce a typed list of proposed tasks; the human reviews them; Execute runs (with execute consent scopes) actually do work.

# ONTO pattern
plan = onto.run_sync("Plan a trip to Lyon.", mode="plan_only", consent_scopes=["tasks:write"])
# Human approves tasks via your UI.
for task in plan.tasks:
    if approved(task):
        onto.execute_task(task, consent_scopes=["tools:web.fetch"])

The human reviews structured data, not a transcript. Approval is per-task. The execution step is a separate run with separate scopes.

Where AutoGen’s approach wins

• Conversational workflows. When the human’s interactions are short, frequent, and feel like chat (“can you also book the train?”), AutoGen’s structure is natural.
• Multi-agent collaboration with a human peer. “Three agents and a human collaborating” is a coherent shape in AutoGen.
• AutoGen Studio. The UI layer for building and inspecting flows is mature.

Where ONTO’s approach wins

• Auditable approval. Plan Mode produces typed Task objects with arguments, costs, and rationales. The approval decision is a row, not a turn in a chat. For regulated workflows, this is decisive.
• Structural guarantees. ONTO’s Plan Mode is enforced by consent scopes. The runtime refuses execute tools in plan mode. AutoGen’s UserProxyAgent relies on the agents honoring the convention of asking the human — there’s no runtime gate.
• Asynchronous review. ONTO’s Plan / Execute split is naturally async. The human can review a plan an hour later, in a queue, in a different UI. AutoGen’s conversational model is fundamentally synchronous.
• Bulk approval workflows. “Here are 50 proposed tasks across 50 customers, approve / reject / edit in bulk” maps cleanly to ONTO’s Task primitive. Conversational HITL doesn’t.

The structural vs conventional split

The core philosophical difference: AutoGen’s human-in-the-loop is conventional — agents are instructed to ask the human and they do. ONTO’s is structural — the runtime refuses certain tools unless execute scopes are granted, regardless of what the LLM tries to do.

For some use cases (creative collaboration, exploratory work, anything where speed of iteration matters more than guarantees) the conventional approach is better. The friction of a runtime gate gets in the way.

For other use cases (regulated workflows, high-stakes decisions, anything where “the agent asked the human” needs to be provable) the structural approach is required. Without it, your audit story is “we instructed the model to ask, and we hope it did.”

Memory and state

A quick aside since this matters for choosing. AutoGen’s state model is per-conversation; long-running memory across conversations needs a bolt-on. ONTO ships UPO + SMO as the runtime’s memory layer. For agents that need to remember the user across sessions, ONTO has the better story by default.

Open-weight and on-prem

Both can run with open-weight models and on-prem. AutoGen is provider-agnostic and works with any chat-completion-style endpoint. ONTO defaults to open-weight and has Helm + Postgres deployment recipes; AutoGen has fewer turnkey patterns for production on-prem.

A decision flow

Conversational HITL where the human is a peer?         → AutoGen.
Structured approval over typed tasks?                  → ONTO.
Multi-agent prototype with a human in the chat?        → AutoGen.
Production agent with audit + memory + on-prem?        → ONTO.
Want a UI-builder for the flow?                        → AutoGen Studio.
Want a runtime that refuses tools without consent?     → ONTO.

A summary

AutoGen and ONTO both take human involvement seriously; they just bet differently on what shape the involvement should take. AutoGen bets on chat. ONTO bets on structured tasks.

For experimental, conversational, and creative work, AutoGen’s bet pays off. For production, regulated, and audit-bound work, ONTO’s bet pays off.

It’s not a “which is better” question. It’s a “which shape matches your workflow” question.

---

The Plan Mode explainer covers ONTO’s approach in depth. The comparison page has the full matrix.

Frequently asked questions

Is AutoGen still active?

Yes — Microsoft Research has continued investing in AutoGen, and the AutoGen Studio + AutoGen v0.4 architecture (async, event-driven) is a significant evolution. It remains one of the more interesting multi-agent frameworks.

Does AutoGen have plan mode?

Not as a runtime invariant. AutoGen supports human-in-the-loop through the `UserProxyAgent` pattern — a designated agent represents the human and can interject. ONTO's Plan Mode is enforced by consent scopes at the runtime level.

Which has better human-in-the-loop?

Different shapes. AutoGen's UserProxyAgent is flexible — the human can be a peer in the conversation. ONTO's Plan Mode is structured — humans approve specific proposed tasks before execution. Pick by which model fits your workflow.