The LLM agents in AG2 Assistant — who they are, their tools, their prompts, and where the design is currently disconnected. A working note for review (June 2026).
Superseded (July 2026). The task subsystem described below
(chat agent → planner → executor(s) → verifier → controller, with plans, subtasks,
deliverables, and an intake step) was replaced by the Cowork-style tasks redesign:
a Task is just standing config (name + prompt + optional model + schedule), and each
Run is a single ordinary turn of the one universal agent on its own chat stream
(task-run:<run_id>) — no planner, no subtask tree, no verifier, no
separate controller agent. See architecture.md (§5.5
"Task subsystem" and §6 "Agents & LLM calls") for the current design; this page
is kept as the historical note that motivated the redesign.
AG2 Assistant runs five distinct LLM agents (plus two non-conversational passes), each created in a
different module with its own model, tools, and prompt. Work flows between them as a relay — and because
each is a fresh agent with a partial view, capabilities like scheduling are known to some and
invisible to others. That fragmentation is the source of the rough edges.
player flow: the chat agent spawns a task; a planner turns the request into a plan; the runner drives executor agents per subtask; a verifier gates each deliverable; the controller edits the task from its chat.
The five agents
#
Agent
Created in
Model
Tools
Prompt (per turn)
1
Chat agent the conversational assistant
agent.create_agent (gateway / channels)
main
web search, web_fetch, read_file 🔒, shell 🔒, code 🔒, skills, Google (when signed in) + start_task + schedule_task
turn_prompt: persona + BEHAVIOR_GUIDANCE + GOOGLE_GUIDANCE (if signed in) + live env
[_CONTROL_PROMPT, live task snapshot] — no persona / behaviour / env
🔒 = permission-gated. Plus two non-agents: a memory-aggregation summarization pass (cheap model) and onboarding (scripted Q&A via the Asker, no LLM).
Prompt summaries
BEHAVIOR_GUIDANCE — shared by agents 1 & 3 only
Do what's asked with the right tool; don't shell-flail or improvise; you can't watch video/audio;
ask the user when you genuinely need info or confirmation.
_PLAN_PROMPT — agent 2 (planner)
Classify trivial vs non-trivial; ask 2–5 clarifying questions about scope, audience, format, depth,
deadline; emit objective + deliverables + subtasks + per-piece capabilities. Final deliverable
belongs to the root and is synthesised from subtasks.
executor message — agent 3
Produce the actual deliverable content with your tools; here's the original request, objective, parent
context, completed-subtask results, and the deliverables to produce now; involve the user if you need to.
verifier — agent 4
Strict check: is the finished deliverable content present and meeting the criteria? For web research, is
it grounded in the retrieved sources? (Asking clarifying questions mid-turn is fine; punting is not.)
_CONTROL_PROMPT — agent 5 (controller)
You steer ONE task. Use your tools to add/cancel subtasks, change the objective, reschedule, or cancel —
immediately, then confirm. Use reschedule for timing changes, never a subtask. You do NOT do
the work yourself — the runner does.
Why it feels disconnected
1. Scheduling isn't a shared primitive — it's tools bolted onto one agent.
Only the chat agent knows scheduling (schedule_task). The planner has no concept
of it, and _PLAN_PROMPT literally invites "deadline" questions — so when a scheduled
task runs intake, the planner asks the user how/when to schedule, re-litigating something already decided.
The controller has reschedule but via yet another prompt. No agent treats "this task has
a schedule" as known metadata.
2. Shared prompt fragments are applied inconsistently.
Persona + behaviour + env reach the chat & executor agents (via turn_prompt); the
planner gets persona-only; the controller and verifier get neither. Tone and rules drift
between stages.
3. The pipeline is a relay of partial views.
chat → planner → executor → verifier → controller, each a fresh LLM that re-derives context from a
hand-built message. None sees the task's full metadata (schedule, origin, capabilities, intake answers) in
a uniform way — the planner never receives the schedule, the controller gets a text snapshot, the executor
gets a different hand-assembled blob.
4. The planner is a heavyweight agent used for a single structured call
and carries unused web/shell/Google tools. Conceptually it's just "request → TaskPlan."
The shape of a fix
Direction only — nothing built yet.
One task-context object. Build the task's metadata (schedule, origin, capabilities, intake
answers, objective) once, via a shared helper, and give it to every task-stage agent — so the
planner knows "this is scheduled weekdays 5am; don't ask about timing," and the executor/controller
see the same thing.
Scheduling as native task metadata, not a per-agent tool. The chat/controller set it; the
planner is explicitly told it's out of scope; the executor/verifier ignore it.
One shared base prompt (persona + behaviour) layered under all task agents
(planner, executor, controller, verifier), with stage-specific instructions on top — replacing the
three bespoke prompts.
Make the planner a thin "request → TaskPlan" call without the unused tool surface.