ait-agent: Optional Transport Manager
Understand the optional 1.0.0 transport-manager boundary, its four worker families, lifecycle commands, and relationship to the coding client and native worker executable.
Audience: Agent operators, integration maintainers, and Repository owners
Role in ait-native#
ait-agent is the optional native manager for Repository-scoped Telegram, LINE, Discord, and Slack workers. It is a standalone executable, separate from the main ait CLI: 1.0.0 has no root ait agent namespace, so an operator installs and supervises the transport surface through ait-agent directly.
It is not the primary coding application. Normal interactive work continues in the coding client that already owns the user conversation and Repository session. Install this component only when a headless transport endpoint is a real operating requirement.
Manager and worker boundary#
| Component | Responsibility |
|---|---|
ait-agent | Add, list, inspect, start, stop, restart, read logs, and remove named worker configurations. Telegram also exposes a supervisor lifecycle. |
ait-agent-worker | Run the selected native transport, verify ingress, invoke the bounded reply provider, and deliver the reply. |
| Coding client | Own the main interactive coding experience and decides when authorized AIT workflow commands are run. |
ait-server | Own optional remote Repository authority, offsite preservation, recovery state, and Worker Jobs. |
Starting a transport worker does not itself create a sprint card, Task, Snapshot, Patchset, or Land. Those remain explicit repository workflow operations performed by an authorized client.
Public command families#
All four transports expose these lifecycle groups:
add list status start stop restart logs removeTelegram additionally exposes:
supervisor status supervisor start supervisor run
supervisor stop supervisor restartRead-only orientation examples are:
ait-agent telegram list --json
ait-agent telegram status main --json
ait-agent telegram logs main --lines 100
ait-agent telegram supervisor status --jsonThe add commands accept transport credentials and lifecycle paths. Their exact required options differ by transport; use the generated standalone `ait-agent` reference instead of copying options between Telegram, LINE, Discord, and Slack.
Configuration and secret boundary#
Manager commands write named entries in .ait/agent-workers.json and maintain their runtime metadata. Credentials must be handled as secrets: avoid retained shell history when a command requires a token, restrict the worker environment and runtime files, and never publish logs or configuration copies without redaction.
The field-by-field manifest, credential precedence, transport defaults, reply provider, and sandbox controls are documented in Agent-worker Configuration. The executing process contract and signed one-shot commands are documented in ait-agent-worker.
Operating decision#
Use ait-agent when a managed external transport materially helps an operator reach one Repository. Do not add it merely to reproduce a coding-client UI or to place messaging inside the core architecture. The local CLI, native bindings, Task isolation, Binary DB, and optional server/runner path remain complete without this manager.