> For the complete documentation index, see [llms.txt](https://docs.talus.network/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.talus.network/faq/02-concepts.md). # Concepts {% hint style="info" %} **Audience:** Nexus adopters and integrators. **Goal:** Answer common vocabulary questions that help a junior developer distinguish Agents, Tools, DAGs, and executions. {% endhint %} This page answers the "what is X versus Y?" questions. Read it once so the domain pages don't have to redefine the vocabulary. Each answer stands alone; the [glossary](/glossary/glossary.md) holds the full one-term definitions these comparisons build on. #### Core vocabulary **What is the difference between an agent, a skill, a tool, a workflow, and a task?** They are five distinct things that stack together: * An **agent** is a keyed on-chain identity object. Custody of that object controls the agent — including access to agent-owned children such as its payment vault. An agent is *who* acts; it holds one or more skills. * A **skill** is a named, versioned capability on an agent. Each skill is bound to a specific execution graph (a DAG) and carries the policy for how it is paid for and how it may be scheduled. A skill is *what an agent can do*. An agent tracks its skills by an incrementing skill id. * A **tool** is an off-chain HTTP service or an on-chain Move module that a single graph step invokes. A tool is *a callable capability* named by a fully qualified name (FQN) like `com.example.add@1`. Tools are registered independently and reused across many skills and agents. * A **workflow**, expressed as a **DAG** (directed acyclic graph), is the ordered set of tool-call steps a skill runs. Its vertices are tool calls; its edges carry one step's output into the next step's input. A workflow is *the plan*. * A **task** is the durable unit that holds a skill run's inputs, controller, payment reserve, and schedule policy. A task is *a skill run placed on a timeline*. So: an **agent** owns **skills**; each **skill** runs a **workflow (DAG)** whose steps call **tools**; every run follows **Task → Occurrence → Execution**. `--now` creates an immediately eligible Occurrence under its Task; it does not use a separate immediate-execution model. Scheduling controls when an Occurrence becomes eligible, while recurrence controls how later Occurrences are created. **What is the difference between an agent-funded and an address-funded (user-funded) task or execution?** This is who pays for a run, and it is fixed by the skill's payment policy: * **Address-funded (user-funded)** — the submitting signer supplies the prepayment coin from an address balance for an address-controlled Task. In the standard address-funded constructor, that signer is recorded as the immutable Task controller; an explicit `refund_recipient` is recorded as the `PaymentSourceKind::UserFunded` beneficiary and final address-funded reserve destination, defaulting to the signer when omitted. A later caller or leader may trigger or submit work, but that action does not rewrite the Task's recorded source or controller. * **Agent-funded** — the agent pays out of its own payment vault, up to a maximum budget the skill's policy sets. The payment's source is recorded as the agent's id, and the run cannot exceed the agent's configured budget. Use this when the agent should sponsor its own runs (for example, a scheduled task that fires without a human present to pay). The skill declares which model it uses, so the choice is made when the skill is defined, not per run. The policy `refund_to` address used by a finite-credit or custom entitlement is separate from both the Task controller and the UserFunded beneficiary. The mechanics of budget, locking, and settlement live on the [payments page](/faq/04-payments.md). **What is a leader, and how is it different from an agent?** An **agent** is on-chain state — an identity and its skills. A **leader** is an off-chain *service*: the runtime that watches the chain, calls the tools each step names, and submits results back. Agents describe *what* should happen; a leader performs the off-chain part a smart contract cannot do. Public integrators inspect the leader's registry identity and execution effects; process operation is outside this documentation. **What is a DAG walk, and how is it different from the DAG?** The **DAG** is the static graph — the published plan. A **walk** is one live traversal of that graph during an execution: it starts at the entry ports you provide values for and advances step by step as each vertex's inputs become ready. A single execution can spawn multiple concurrent walks (for example, one per entry vertex in the chosen entry group, or one per element of a looped edge). The DAG is the recipe; a walk is one act of cooking it. **What is a Talus Agent Package (TAP)?** A TAP is user-created package code or package metadata that fits Nexus interface contracts. Nexus supplies the agent, skill, payment, scheduling, authorization, and verification interfaces; a TAP uses those interfaces for its own agent behavior while Nexus remains the source of cross-package compatibility. *** **Where do I go next?** * [Overview](/faq/01-overview.md) — the roles and the execution lifecycle, if you skipped it. * [Authoring](/faq/03-authoring.md) — turn these concepts into a registered tool and a working DAG. * [Payments](/faq/04-payments.md) — how agent-funded and user-funded budgets lock and settle. * [Glossary](/glossary/glossary.md) — the full definition of every term compared here. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.talus.network/faq/02-concepts.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `build a script that syncs our docs to a CMS` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.