Core concepts

These ten terms describe how ATFGraph runs agents. You will see them in the CLI, Console and SDK.

Graph server

The shared service that queues work, routes calls between agent capabilities, stores memory and records execution paths. Clients send requests to the server; workers connect outbound to claim work. Calls between nodes go through the server rather than directly to another worker.

The server binary is atfgraphd. Its default address is 127.0.0.1:18880.

Agent node

An application component with a label (such as hello), a version and a set of capabilities: traversals and skills. In Python, you define a node with an Agent object and run it as an outbound worker, for example with python -m atfgraph.worker.

A registered definition is immutable for its version. To change the capabilities a node offers, register a new version.

Traversal

A function that coordinates work. It can call a model, call other traversals and skills with await app.traverse(...), and combine their results. It does not have to call a model. Declare one with @app.traversal().

Each call through the graph server becomes a recorded step, so you can inspect which capabilities ran and how they relate to one another.

Skill

A deterministic function that performs one operation and returns a result. It can wrap an external API, a database query or a computation. It does not call a model or route work through the graph. Declare one with @app.skill().

This runtime skill is a Python function. A coding-assistant skill is a separate set of Markdown instructions that helps an assistant build or use ATFGraph applications; see Build from a brief.

Traverser

One run of a capability, started by a request or a trigger. It has an ID, input, a status and an execution path. Its status is queued, running, waiting, succeeded, failed, cancelled or timed_out.

atfg traverse starts a traverser, atfg ps lists traversers, and atfg wait waits at the barrier until a traverser reaches a terminal status. Calls to other capabilities create child traversers within the same run tree.

Path

The recorded execution of a traverser and its children: which steps ran, which steps called them, their attempts and their outcomes. Parallel work appears as branches rather than a single sequence.

atfg path <id> reads the path, the Console displays it, and atfg share <id> exports it as a self-contained file. With node identity enabled, signed-path proofs support offline verification.

Step

One recorded capability invocation on a path. It identifies the target, parent step, status, attempts and elapsed time. In the quickstart, hello.greet is step 1. The hello.shout skill it calls is step 2, with step 1 as its parent.

Decision

A traversal for a judgement that returns structured output. Declare one with @app.decision(); the server dispatches it like a traversal and records its kind on the step.

When the model output includes confidence, confidence_field= on app.ai records that confidence and any fallback in the usage record. Teams can then count low-confidence decisions and fallbacks by capability. See Decisions.

Harness

An execution tool that runs an agent's model and tool loop. A traversal can use app.harness(...) to delegate a task to a supported coding-agent CLI, such as ATF Harness, Claude Code, Codex, Gemini CLI or OpenCode.

The adapter starts the CLI in a specified working directory, applies a deadline, handles cancellation and parses the result. Tool controls and reported costs depend on the provider. A working directory alone does not sandbox the process. The path records the calling traversal and progress summaries; it does not turn each internal tool action into a graph step.

Remote mode delegates to an ATF Harness service instead of a local CLI. See Delegating to a coding harness.

Emitter

A server-side trigger definition that starts a traverser when a schedule is due or an event arrives. Examples include cron schedules, inbound webhooks and memory changes. Each emitter targets a capability and has a delivery log.

Teams declare trigger bindings in agent code, or administrators configure them through the API or the Console's Triggers page. For a webhook, the application specifies event types and business conditions; the server authenticates the delivery and suppresses duplicates. See Schedules and webhooks.

How they fit together

1. An agent node registers its label, version and capabilities with the graph server. Its worker then claims work through an outbound connection.
2. A client request or emitter starts a traverser on label.capability.
3. The server queues the task for a worker serving that node and version. Inside a traversal, each app.traverse(...) call goes through the server, which routes the child work and records its step.
4. The completed run leaves a path showing its steps and outcomes. atfg wait returns when the traverser reaches a terminal status.

Two related terms describe shared state. A session groups the runs of one conversation. Memory is persistent state that agents read and write in global, session, actor or workflow scopes. The server supplies storage; your application decides what to store and how to use it. See Sessions and memory.