Charlie is a cloud-hosted, asynchronous software-engineer teammate. He works through the systems engineering teams already use, including GitHub, Slack, and Linear, and returns work to those systems as reviewable results. A request does not need to begin in a separate chat or remain tied to one developer's computer.
This page follows Charlie's architecture from an incoming event through routing, durable execution, coordinated agent work, and external actions.
GitHub, Slack, and Linear events enter Charlie through ingestion, which validates, deduplicates, and enriches them. Routing then decides whether to start a durable Task, continue an active one, or drop the event.
The agent runtime executes the Task with context, tools, and delegation. It uses a devbox containing the relevant repositories, commands, CLIs, and scoped credentials to query and act on those connected systems, returning the result where the team already works.
Agent tasks begin when a person mentions Charlie or assigns work to him. A daemon task
begins on a schedule, or when a Signal matches a watch condition from a DAEMON.md file in the repo.
Agent
Human explicitly invokes Charlie.
Daemon
Event matches daemon watch condition.
DAEMON.md that watched for the event.
Each daemon lives at .agents/daemons/<daemon-id>/DAEMON.md on the repository's
default branch. The file defines its purpose, activation conditions, routines, denials, and operating
policy. Once merged and ingested, the role becomes eligible for activation. Its configuration
remains visible and reviewable by the team.
A webhook event records activity from GitHub, Slack, or Linear. An accepted event produces at most one enriched Signal, which gives routing the context it needs to add a Message to a Task's mailbox or create zero or more root Tasks. A Task is Charlie's durable record of agent work and can delegate child Tasks that retain their parent and root lineage. Scheduled daemon Tasks can also begin without a webhook event or Signal.
Routing consumes a Signal and produces a plan for what should happen next. It combines deterministic policy with semantic decisions: whether the Signal is eligible for normal Charlie agent work, whether it belongs to an active Task, which repository it belongs to, and which daemon roles apply.
For active work, Charlie compares the Signal with live root Tasks for the same customer. A follow-up Slack message can therefore be appended to the Task already handling the conversation instead of starting a competing second Task.
A Task is Charlie's durable unit of agent work. It records the request, the selected repository and agent identity, relevant Signal context, lifecycle state, lineage, and final result.
Each Task has a durable mailbox. If a signal is correlated with active work, routing appends it to that Task instead of creating a competing root Task. The executor checks for mailbox messages and scheduler stop state at defined boundaries, adds new messages to the transcript, and uses them in subsequent work.
Each turn and tool result is appended to a durable transcript. Phase and pending-tool state let the executor resume after a restart and report the final outcome to the scheduler.
A devbox is Charlie's isolated Linux workspace. It contains the selected repository, runtimes, package managers, shell tools, and customer-scoped provider credentials. The agent starts or reuses it and records command results in the run transcript.
Provider CLIs query and update GitHub, Linear, Slack, and Sentry. A task tree may reuse one devbox or reference several devboxes when work spans repositories.
gh, ch-linear, ch-slack,
ch-sentry Charlie delegates work to worker agents. Each delegation creates a child Task with its own identity, lifecycle, role, and repository context while preserving parent and root lineage.
Workers can run in parallel. Workers can delegate to other workers. The parent lists, waits for, and inspects their status and evidence, then combines the results into one customer-facing outcome.
Delegates work, monitors progress, and awaits results.
Tools:delegate_task_to_<worker_name>, tasks_get, wait_for_task Ingestion validates provider deliveries and turns supported events into enriched Signals. Routing decides what those Signals mean and writes new Tasks or messages for active Tasks. The Task system owns durable lifecycle, scheduling, mailbox state, and parent-child relationships. The agent runtime owns an execution attempt, including its context, transcript, model turns, and tool calls. Devboxes provide the isolated repositories, runtimes, command-line tools, and credentials used during execution.
Daemon definitions and schedules converge on the same Task system used for directed work. Once scheduled, both use the same runtime, tools, devboxes, and evidence infrastructure. Identifiers connect the original event to its routing decision, Task, execution, and external result.
The model reasons, calls tools, and delegates work. Services outside the model own Task status, mailbox persistence, and terminal state, so different workflows do not require separate execution systems.