Skip to main content

TinyAGI Architecture and Runtime

1. The workspace shape​

The README already reveals the core product shape:

AreaWhy it matters
agentsisolated workers with specialized roles
teamscollaboration layer for handoffs and fan-out
channelsexternal messaging surfaces
SQLite queueatomic jobs, retries, dead-letter handling
TinyOfficebrowser dashboard and visual control plane

This is a bigger runtime than a normal single-assistant terminal app.

2. The runtime mental model​

At runtime, TinyAGI usually works like this:

  1. a message or task enters the system,
  2. the queue persists and schedules it,
  3. an agent or team processes it,
  4. results are streamed into TinyOffice and logs,
  5. responses can return through channels or stay in the portal.

3. Why the queue matters​

The SQLite queue is not a boring implementation detail. It is part of why TinyAGI can support:

  • parallel work,
  • retries,
  • background operation,
  • and more durable 24/7 behavior.

4. Why TinyOffice matters​

TinyOffice is not just a dashboard. It is the human control surface for:

  • chat,
  • agents and teams,
  • tasks,
  • logs,
  • and settings.

That makes it central to the runtime, especially for non-terminal operators.

5. What to read first in code​

Start with:

  1. the README quick start,
  2. queue and daemon surfaces,
  3. team and agent code,
  4. TinyOffice-related areas,
  5. channel adapters last.