Events
Every run yields a typed AgentEvent stream — the single channel for streaming text to a UI, showing tool activity, and servicing approvals and user questions. Events are observe only: handling them never changes agent behavior, so you can build any rendering or logging layer on top without touching the agent.
You already consume the stream whenever you iterate query():
Events forwarded from a subagent carry an agentId; the main agent's events don't.
Rendering text
Text arrives incrementally as text_delta chunks — write them through for a streaming UI. When a turn's full assistant message is ready, a message event carries it; when the whole run finishes, done carries the final RunResult:
Interactive events: approvals and user input
Two event pairs correspond to points where the run suspends and waits for your handler:
approval_request→approval_resolved— the permission gate returnedaskfor a tool call; youronApprovalhandler answers"allow"or"deny". See Permissions.input_request→input_resolved— the model calledask_user; youronAskUserhandler returns the answer string.
Use the events to render the prompt in your UI (e.g. show which tool call is awaiting approval); use the handlers to actually answer. The run blocks until the handler resolves.
Full event reference
See also
- Agent loop — the five steps that produce these events.
- Sessions — events are what gets persisted per session.
- Permissions — the approval flow behind
approval_request/approval_resolved. - Core strategies —
ApprovalHandlerandInputHandlerinterfaces.