From Embedded Assistant to Production System
Agentao becomes useful when its governed-runtime model is matched to the product around it. The final question is not “which feature should every agent use?” but which combination of process boundary, capability surface, policy gate, execution isolation, state, evidence, and budgets fits the actual work. This conclusion compares the documented product shapes, turns the authority model into a launch decision, and keeps the final judgment within what first-party repository evidence can—and cannot—prove.
Choose the boundary by the product shape
A tenant-scoped in-product assistant is usually a stateful application feature. Users expect a continuing conversation, streamed text, and access to a small set of business operations. The documented SaaS blueprint places one Agentao instance behind a FastAPI service for each tenant and session, binds custom Tools to tenant identity, and streams events to the browser. The Python SDK is a natural fit when the host already owns the session pool and the application benefits from direct callbacks. The non-negotiable conditions are explicit working directories, serialized turns, per-tenant Tool construction, a policy that distinguishes reads from writes, and a cleanup path for evicted sessions.
An IDE or editor plugin has a different boundary. Its host may be TypeScript, Kotlin, Rust, or another language, and its user interface already has a process and approval model. The ACP blueprint fits that shape because Agentao can run as a subprocess for the workspace. The plugin renders session/update notifications, turns permission requests into editor prompts, and uses session loading after a restart. The cost is that the plugin must implement framing, dispatch, timeout, process recovery, and response handling. ACP is not better because it is more standardized; it is better when language independence or process isolation is part of the product’s requirements.
A ticket-automation worker is neither a chat UI nor an IDE. It receives a job, gathers CRM and knowledge-base context, drafts a response, and may send only when a confidence and policy gate permit it. The guide’s blueprint favors a fresh or narrowly scoped in-process session, custom Tools, a support Skill, an explicit human handoff, and idempotency keyed to the ticket. The important design choice is not streaming. It is making “draft” and “send” different capabilities, ensuring retries do not send twice, and leaving an auditable reason when the agent declines to act.
A data workbench is defined by its execution boundary. The user may ask for a chart in plain language, but the agent may need to run SQL, write a script, and save a file. The blueprint combines skills that require schema inspection and visible SQL with a per-session workspace, a read-only data mount, and a no-network shell profile. Here the sandbox and filesystem layout matter more than a broad tool catalog. The product should make the generated query visible and limit the writable area, because a confident answer is not proof that the model interpreted the data correctly.
An unattended scheduled job has no person to approve a prompt in the middle of the run. The batch blueprint therefore emphasizes explicit allow/deny policy, small budgets, idempotent outputs, fail-loud errors, and a machine-readable result contract. A job that silently auto-approves a write or quietly produces an empty report is not “headless convenience”; it is an unreviewed authority path. The host must decide in advance what the job can do, what counts as a valid result, and which failure should stop delivery.
These shapes lead to conditional boundary choices. Use the Python SDK when the host is Python and needs direct, stateful, low-overhead integration without a strong process boundary. Use ACP when the host is not Python, when an IDE or tenant needs crash containment, or when dependencies and credentials should be separated. Use a hybrid when a long-lived Python flow should delegate a narrow, isolated specialist task. The hybrid is not a universal upgrade: it adds another process, session lifecycle, log, and policy path, so its isolation or interoperability benefit must justify that cost.
The selection can be made on four dimensions rather than by product label alone.