Tools

Tools are the operations that Deepline exposes for working with data and connected services. A tool has an identifier, declared inputs and outputs, access requirements, and pricing behavior. It can retrieve company details, verify an email address, query a warehouse, or update a connected CRM record. The Tools catalog groups maintained workflows, provider operations, and Monitors. It helps you find an existing capability before building custom logic. The CLI and API expose the same underlying catalog, so an agent can discover and inspect the available operations.

​

Workflows, operations, and feeds

A maintained workflow is a prebuilt Play that combines steps for a defined result. A provider operation is a tool call to one exposed action. A Monitor keeps a supported provider event feed active over time. For example, a prebuilt work-email Play can combine several lookup and verification operations. A direct verification tool checks one supplied address. A Monitor supplies new events that a Play can process later. These capabilities can work together, but they have different inputs and lifetimes.

​

What tools can do

The selected operation defines the exact inputs, returned evidence, and acceptance or validation rules. Two tools in the same category can serve different questions.

​

AI operations

Deepline exposes AI operations as callable tools. ai_inference generates text or structured JSON from a prompt and supplied context, without tool access. ai_evaluate answers typed questions about a supplied record, such as a score, choice, or yes/no decision. The deeplineagent operation handles a multi-step task with a Deepline-managed set of tools. Its available tools include web search, page retrieval, scoped crawling, and an isolated Bash workspace. The request can supply a prompt or messages, a model, a structured-output schema, and limits on tool calls. Deepline controls the available tool set on the backend. For example, a Play can give the agent an account domain and a specific research question. The agent can find relevant pages and return structured findings. The Play can retain those findings as a dataset column beside the input domain, then use deterministic rules or a separate review to decide what happens next. Structured JSON provides a usable shape, not proof that every generated claim has reliable evidence. These AI operations execute as part of a request or Play. Your external coding agent serves a different role: it discovers tools, authors Plays, and operates runs through Deepline’s interfaces. The AI action is a step that this workflow can call, rather than a deployment of your external agent.

​

Discovery starts with the input and result

Search is most useful when it describes both what you have and what you need. “Person name and company domain to work email” is more specific than a provider name alone. A provider-specific search is useful when your task requires that provider or an existing account’s records. Search returns candidates. Describing a candidate reveals its input fields, output fields, connection requirements, and applicable pricing. These details determine whether it fits the task. An operation that returns company records does not necessarily accept the same identifiers or supply the same evidence as another company operation. Discovery also reflects availability and workspace access. A listed provider connection and a callable action are separate capabilities. A saved connection does not create actions that the public catalog does not expose.

​

Direct calls and Plays

A direct tool call is useful for a specific operation with known inputs. It returns that operation’s result and any execution metadata. The selected tool’s generated action reference describes its fields and behavior. The Runtime API reference covers Deepline’s request interfaces. A Play adds reusable logic around tool calls. It can map the operation over a dataset, combine several sources, apply acceptance rules, branch on a result, and retain computed columns. A prebuilt Play supplies maintained logic for a supported task. A custom Play supplies your own logic. For example, a direct tool can inspect a CRM record. A repair Play can compare that record with several sources, retain a proposed change, and apply only the fields allowed by the team’s policy. Waterfalls are one way a Play can combine operations until a result meets an acceptance rule.

​

Results, access, and effects

A completed operation can return no result. An authorization failure, provider error, or uncertain response needs different handling. Keeping these outcomes separate prevents a failed request from being treated as evidence that a person or company does not exist. Some operations only read data. Others create, update, delete, enroll, or send. The action contract and connected account permissions determine the effect. For an uncertain direct response, tool request recovery explains how to inspect existing work before submitting a replacement. Integrations explains managed access, workspace connections, and BYOK. Choose a prebuilt Play and the API reference cover the next steps for using a selected capability.