> 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/01-overview.md). # Overview {% hint style="info" %} **Audience:** Nexus adopters and integrators. **Goal:** Find the right Nexus documentation path for a development or operating question before choosing a command or integration surface. {% endhint %} This page is the evaluator's entry point: it answers "what is Nexus, and is it right for me?" in a few paragraphs, then hands you to the concern-specific pages. Every answer here stands alone; where a distinction needs its own treatment, it lives on the concepts page. #### What Nexus is and who runs it **What is Nexus?** Nexus is an on-chain protocol on Sui plus an off-chain runtime for building, running, paying for, and verifying agentic workflows. The protocol is a set of Move packages that define the durable objects and rules — agents, skills, tools, the execution graph, payment, authorization, verification, and scheduling. The off-chain runtime is the **leader**: a service that watches the chain for execution events, invokes the tools each step names, and submits the results back on-chain. The chain is the source of truth for *what* should run and *what* the rules are; the leader does the *off-chain work* a smart contract cannot do itself, such as calling an HTTP API. **What are the roles, and which one am I?** Four adopter roles show up across this FAQ: * **Evaluator** — deciding whether Nexus fits. Start here and on the [concepts page](/faq/02-concepts.md). * **Tool provider** — building and exposing a tool (an off-chain HTTP service or an on-chain Move module) that workflow steps call. See the [authoring page](/faq/03-authoring.md). * **Agent developer** — defining an agent and its skills, wiring tools into an execution graph, and running executions. See the [authoring](/faq/03-authoring.md), [payments](/faq/04-payments.md), and [authorization](/faq/05-authorization.md) pages. * **Integrator** — consuming public protocol state through Vision Explorer, the hosted API, CLI, or SDK. Leader process operation is outside the public adopter docs. One person often wears several hats; the FAQ is organized by *concern*, not by role, so you open the page for the question you have rather than the badge you wear. **How does an execution actually happen, start to finish?** An agent’s skill is bound to a **DAG** (a directed acyclic graph of Tool-call steps) published on-chain. Every run first creates a Task; its Schedule creates an Occurrence, and dispatch creates the Execution. `--now` makes that Occurrence immediately eligible rather than bypassing the Task lifecycle. A leader observes ready work, invokes the registered HTTP or Move Tool, and submits the result on-chain. The result feeds later steps until the DAG reaches an output or a failure policy applies, while payment locks settle along the way. **Where is my data stored?** Storage is selected per value, not automatically by size or sensitivity. `NexusData` may carry an object reference, inline canonical JSON bytes, or a digest-bound Walrus reference. CLI `--remote` explicitly materializes selected fields remotely; other fields remain inline unless the command's documented size handling requires otherwise. A remote reference can outlive its retained value, and retention, restoration, and cleanup remain provider/operator responsibilities. Remote storage is **not** an encryption boundary, so keep secrets inside the Tool runtime. See [Troubleshooting](/faq/08-troubleshooting.md). **How mature is Nexus? Can I build on it now?** Nexus is a working system you can build and run against: tools register, agents and skills publish, DAGs execute and settle, payments lock and refund, tasks schedule, and results verify. Some capabilities are narrower than the type system’s eventual shape—the [verification page](/faq/06-verification.md) names the active verifier modes. This FAQ documents implemented behavior and states unavailable capabilities plainly rather than promising them. **Deciding what to build** **How do I decide what kind of agent or tool to build?** The decision spans every domain, so treat this as an orientation and follow the links: * **Do you want to expose a capability others call, or orchestrate calls into a workflow?** Exposing a capability means building a **tool**; orchestrating means defining an **agent** with **skills** that wire tools into a DAG. The [concepts page](/faq/02-concepts.md) draws these distinctions precisely. * **Is your tool's work off-chain (call an API, run a model) or on-chain (mutate Sui state)?** That picks an off-chain HTTP tool versus an on-chain Move tool — see the [authoring page](/faq/03-authoring.md). * **Who supplies a run's Task reserve — the submitting signer from an address balance, or the agent's own vault?** That is the address-funded/user-funded versus agent-funded choice on the [payments page](/faq/04-payments.md). * **How much trust does a result need?** That is the verifier-mode choice on the [verification page](/faq/06-verification.md). * **Does the work run on demand or on a schedule?** That is immediate versus scheduled execution on the [scheduler page](/faq/07-scheduler.md). Deep step-by-step tutorial belongs in [Define an Agent package](/guides/agent-usage/build-agent-package.md); this FAQ gives you the grounded orientation and the concern page to read next. **Concept quick-reference** These one-line pointers disambiguate the core vocabulary, each redirecting to its full definition in the [glossary](/glossary/glossary.md); the [concepts page](/faq/02-concepts.md) expands the comparisons. * **Agent:** a keyed on-chain identity created with a standard `AgentPaymentVault`; Agent-funded payment is optional, but the vault object itself is not. [Glossary](/glossary/glossary.md) * **Skill:** a named, versioned capability on an agent, bound to a DAG and carrying its payment and schedule policy. [Glossary](/glossary/glossary.md) * **Tool:** an off-chain HTTP service or an on-chain Move module that a DAG step invokes. [Glossary](/glossary/glossary.md) * **Workflow / DAG:** the directed acyclic graph of steps a skill runs. [Glossary](/glossary/glossary.md) * **Task:** a scheduled unit: a skill execution the scheduler fires over time. [Glossary](/glossary/glossary.md) * **Leader:** the off-chain service that drives executions. [Glossary](/glossary/glossary.md) * **Talus Agent Package (TAP):** user-created package code or metadata that fits Nexus interface contracts for agents, skills, payments, scheduling, authorization, and verification. [Glossary](/glossary/glossary.md) *** **Where do I go next?** * [Concepts](/faq/02-concepts.md) — the precise difference between agent, skill, tool, workflow, and task, and between address-funded/user-funded and agent-funded runs. * [Authoring](/faq/03-authoring.md) — building tools and wiring workflows. * [Concepts](/concepts/08-registries-and-discovery.md) — public Leader selection, identity, and dispatch role. * [Define an Agent package](/guides/agent-usage/build-agent-package.md) — turn the selected model into a validated skill package. * [Glossary](/glossary/glossary.md) — plain-English definitions of every term above. --- # 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/01-overview.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.