Discussion: native agents, scoped delegation and verified background completion

Direction

Mu is the runtime for agents and services; Micro is the first product and its default personal assistant. A specialist should normally be a stored definition—name, objective, instructions, scoped tools and optional model—using one shared execution loop, not another hand-coded Go loop or dedicated process.

Related: #1513 (durable service runtime), #1630 (installing external agents/services). This issue develops agent execution and identity, rather than replacing those proposals.

Existing foundation and gaps

The roster already stores hosted agent definitions, and AskAs applies their instructions, service scope and model to the shared loop. Background work already routes results to tasks/conversations/mail. The native loop is bounded (40 steps and a five-minute turn timeout).

However:

• Task creation exposes me/agent assignment, while the worker can resolve named agents: assignment and UI/API plumbing are uneven.
• Task creation within an agent run deliberately avoids automatically starting another run. Keep this recursive-task guard until explicit delegation semantics replace it.
• Interrupted doing tasks become blocked after restart; this is not checkpointed resumption.
• An empty service scope currently means all owner-accessible services; narrow defaults and explicit grants need a deliberate contract.
• A missing named agent must not silently cause work to execute under a different identity or broader authority.

Work to define and implement incrementally

• Separate agent definition, activation trigger, conversation/session and individual work/run identity. Creating an objective must not start an unbounded permanent loop.
• Make agents visibly distinct native participants: Micro · Agent in recipient lists; purpose/capabilities on profiles; Message and Assign task; attributed output and visible assigned work. Reuse chat/mail/tasks/events rather than requiring a separate agent messaging service.
• Support named assignees consistently across task API, UI and worker.
• Define explicit parent/child delegation: objective, acceptance criteria, parent run, assignee, inherited or narrower grants, progress/result return, cancellation and bounded depth/concurrency/cost. A child cannot grant itself additional authority.
• Persist enough state to recover work independently of the browser and process. Define waiting/blocked/failed/completed outcomes, checkpoints and safe resumption. Do not blindly replay external side effects.
• Define completion as evidence of the requested outcome. Successful tool calls or a final model paragraph are insufficient. Report blockers and incomplete verification honestly.
• Make progress, tool failures, partial work and terminal results inspectable by the owner and delegating agent.
• Keep conversation context bounded; distinguish durable work state and memory from blindly accumulating chat history.

Concrete failure to use as an acceptance case

The live task “Add and verify Copy answer in the Assistant app” was marked done. Its result contained app metadata, “No problems found”, an embed snippet and generic assistant text. Recorded steps included reads, shell calls and apps_test, but no apps_edit/publish operation. It did not report the requested backup, implementation, clipboard checks, responsive/streaming verification or publish evidence. Successful inspection was treated as successful completion. This is an observed task-record failure; live source verification remains separate.

Acceptance: Micro must either deliver and verify the requested app change with recoverable source and a URL, or leave an explicit incomplete/blocked outcome. The same requirement should hold for a delegated subagent.

go-micro / Mu boundary

Prove behavior in Mu first, with go-micro pinned and small local adapters when necessary. Promote demonstrated reusable mechanisms upstream once the contract is clear, rather than requiring a framework release for every product iteration.

Likely reusable harness responsibilities: model/tool execution loop, cancellation and execution/checkpoint extension points. Mu owns account/agent identity, grants, work storage, triggers, conversation integration, delivery and product completion policy. Settle the boundary through working examples; avoid both bespoke loops per specialist and premature framework APIs.

First slice

Use one named specialist running the shared loop on an explicit task. Show bounded tool access, visible progress, verified completion or an honest blocker. Then add one parent-to-child delegation and an interrupted-work recovery case. No wholesale rewrite, one-process-per-agent requirement or marketplace prerequisite.

Start by tracing the existing roster, AskAs shared execution loop, task API and worker, then implement the stated first slice: one named specialist on an explicit task with bounded tools, visible progress and verified completion or an honest blocker. Use the Copy answer task as the acceptance case, ensuring the outcome distinguishes evidence of the requested change from inspection alone; then review the parent-to-child delegation and interrupted-work recovery cases.