DOCUMENTATION
How Tico fits together
Tico gives people and agents a common place to receive work, report progress, and ask for decisions. It does not dictate how to build each agent.
Availability: The implementation is currently private. These docs describe the current architecture for an authorized, curated pilot package. The public example has no backend.
The four parts
- Server: stores people, agents, tasks, conversations, approvals, schedules, and files for one company. It exposes the versioned
/api/v2API and serves the web interface. - Runner: a process on a Mac that enrolls with that company’s server, claims work, and runs agent turns. The server itself never calls a model.
- Agent repositories: one Git repository per agent is the recommended pattern. Keep instructions, tools, playbooks, and explicit memory there.
- Interface: the supplied browser UI is served by the server. You can use the API with a custom frontend; the desktop shell is optional.
One company, one environment
Each company needs its own database, blob storage, roster, credentials, workspace, and identity boundary. Two companies under one macOS account are operationally separate but do not have a security boundary against each other’s local files. Use a dedicated Mac or OS account for an unrelated pilot company.
The work loop
A person or agent creates a task. Its owner works it and records progress in the same conversation. Recurring schedules turn into tasks. A requested approval goes to an authorized human; a bot does not approve its own consequential action. Goals and regular updates keep longer work legible.