> ## Documentation Index > Fetch the complete documentation index at: https://deepline.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Design for agents > How Deepline's CLI, SDK, typed Plays, and observable runs support reliable agent work. An agent integration needs more than a tool that accepts a prompt. It needs a way to discover valid operations, inspect results, and decide what to do when the response is incomplete or an external action is uncertain. Deepline separates discovery, execution, and observation so that the agent can reason about each boundary. Skills provide context, interfaces expose operations, and Plays preserve executable logic outside a conversation. ## Discovery reduces the cost of guessing A provider name does not identify one universal input schema. Different actions can accept different identifiers, expose different outputs, or support different billing modes. A remembered example can be syntactically plausible and still be wrong for the current operation. The live search and describe surfaces allow an agent to find a candidate and inspect its contract before execution. Search supplies possibilities; the contract supplies the input and output rules. A result's title alone does not establish that it fits the request. This is especially important for prebuilt Plays. Two workflows that both find email may require different identity inputs or return different shapes. The choice should follow the contract, not a guessed identifier. ## A Play gives a conversation a durable artifact An agent can explore a problem interactively, but recurring work needs a stable description of the decision. A Play holds that description in code, with typed inputs, admitted runtime operations, and identifiable versions. The agent can revise the source, validate its supported structure, and inspect a pilot. Once submitted, execution runs in Deepline rather than depending on the agent continuing its conversation. A trigger can later invoke the admitted logic without asking the model to reconstruct every decision from scratch. That separation also exposes what remains the agent's responsibility. Authoring checks do not prove that a business criterion is appropriate, that a source is reliable, or that a destination write is authorized by the team. ## Machine-readable output and human review serve different readers Structured output lets a caller distinguish identifiers, statuses, results, errors, and next-page instructions without interpreting terminal decoration. Human-readable output remains useful when someone is reviewing a command. A result should be interpreted at its own layer. An empty successful database query means no matching rows. A tool returning no usable contact is a different outcome from a failed provider request. A completed Play can legitimately return an unresolved match if its code treats that as an output. These distinctions let an agent choose a different source, request review, or stop with a reason. Hiding failures behind generic success prevents that choice. ## Small pilots reveal semantic problems Static checks can reject unsupported authoring shapes. A representative pilot can reveal that a schema-valid input names the wrong person, a field is absent in real responses, or a proposed update disagrees with existing CRM data. For example, ten account rows with known expected outcomes are more informative than a larger unreviewed run. A disagreement between a source observation and a CRM value needs a precedence policy; simply adding more provider calls does not resolve that policy question. A pilot still executes real work unless the particular operation offers a non-executing check or preview. Small is a scope choice, not a universal dry-run mode. Potential external writes need explicit controls in the authored logic. ## Observation lets the agent recover without repeating the request A remote run has an identity that remains useful after the initiating client stops waiting. Reading its status or retained result is different from starting another run. A local timeout does not prove that remote execution stopped. Direct tool execution also has a public caller-owned idempotency contract. It is distinct from a Play's internal call labels and completed caches. An integration must use the recovery mechanism for the operation it actually started, rather than assuming every repeated command is harmless. ## Interfaces fit different execution environments Shell-capable coding agents can use the CLI. TypeScript applications can use the SDK. HTTP and MCP fit environments that require those boundaries. Skills help an agent choose and use the surface; they do not grant new workspace permissions or replace authentication. The common model makes it possible to move from interactive exploration to application-owned execution while retaining the distinction between source, run identity, and business outcome. ## Continue learning * [Coding agents](https://deepline.com/docs/sdk-v2/coding-agents.md): installation, discovery, and the pilot review checklist. * [Write Plays](https://deepline.com/docs/sdk-v2/plays.md): author and validate executable logic. * [Production integration](https://deepline.com/docs/sdk-v2/production-integration.md): observe the same run across disconnects. * [Tool execution recovery](https://deepline.com/docs/sdk-v2/tool-execution-recovery.md): the direct-call idempotency contract. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.