Skip to content

Core concepts

A few simple ideas describe everything in Chronos. Once these click, the rest of the product is intuitive.

A workspace is a repository you’ve connected to Chronos — for example by opening it with chronos .. Each workspace remembers a few settings — most importantly its base branch (the branch your work starts from and is compared against, such as main) and the remote used for pull requests. You can have several workspaces open at once.

A session is one unit of work. Each session runs in its own isolated git worktree on its own branch (chronos/<id>):

  • It never touches your main branch and never affects other sessions.
  • You can run many sessions in parallel — one per task — without them interfering. Sessions are not copies of the repository; they share its object store, so creating one is fast and cheap.
  • Each session keeps its own history, so you can step away and come back to it later.
  • When you’re done, closing a session cleans everything up — worktree removed, branch deleted, no leftovers.

Think of a session as a private, disposable space where an agent does one job and you review the result.

A sequence is the list of instructions you send to a session, worked in order. You can give the agent a first task, then queue follow-ups (“now add tests”, “update the changelog”) and let it work through them one at a time.

Chronos drives AI coding agents on your behalf, and each supported agent sits behind an adapter — a swappable runner with a common interface. You choose which agent handles a session, and your organization decides which agents are available. Chronos orchestrates the agent — running it, streaming its progress to you live, and applying its work inside the isolated session. Because adapters share one interface, switching agents never changes how you work.

The broker is a local proxy that sits between the agent and any external tool or data source. When an agent needs a connection your organization has approved, the broker injects the credential on the agent’s behalf — the agent only ever talks to localhost, and never sees the secret or the real endpoint. The broker listens on loopback only and validates every call, so no other process on the machine can use it.

The catalog is the signed list of tools, connectors and capabilities your organization has authorized, delivered from the enterprise panel. It cascades from global defaults to per-team entries, so each team gets exactly what it has been granted. Chronos verifies the catalog’s signature before using it — an unsigned or tampered catalog is rejected, never silently accepted. An agent can only reach what the catalog allows; some capabilities you can toggle per session, others are always on because your organization requires them.

Together, these pieces are how your organization stays in control:

  • Approved tools and data only — agents can use only what the catalog authorizes.
  • Credentials are never exposed to the agent — the broker handles every connection.
  • Policy-gated merge — code reaches your main branch only after your checks pass and the right people approve.
  • Complete audit trail — every instruction, change, approval and merge is recorded.
Workspace (a connected repository)
└── Session (isolated worktree, on its own branch)
├── Sequence (your instructions, in order) ──▶ handled by an agent (adapter)
├── Catalog (signed list of approved capabilities)
└── Broker (governed connections — credentials never exposed)

Everything above is recorded in a complete, tamper-proof audit trail.

Next: Installation.