Skip to main content
Deepline is built around one observation: AI coding agents are not just users — they’re a fundamentally different kind of user. Every design choice in Deepline starts from “what would make Claude Code, Codex, Cursor, Gemini CLI, Antigravity, Hermes, or another coding agent succeed here?” This page explains the principles, the interfaces we ship, and why our recommended primitive is the CLI for coding agents.

​
The three principles

​
1. Text-first output, not JSON-first

Agents are language models. They parse text natively. Every Deepline command outputs human-readable structured text by default (CSV, formatted tables, markdown summaries). Use --json only when piping to another program. Why: When an agent reads deepline tools list, it sees a sortable table it can reason about. When it reads JSON, it has to parse, then summarize, then plan. That’s two extra reasoning steps per call.

​
2. Composable Unix-style commands, not monolithic workflows

Each Deepline command does one thing: enrich, tools search, tools execute, auth status. Pipelines are built by chaining commands, not by configuring monolithic workflow objects. Why: Agents are good at composing 4 simple commands; they’re bad at filling in 47 fields of a workflow config. Compose > configure.

​
3. Failure modes are loud, not silent

Per our internal contributor guide: “Loud failures + short circuits > fallbacks.” When a provider goes down, Deepline returns a clear error. We don’t silently route to a worse provider or return partial data. Why: Agents debug by reading error messages. Silent fallbacks make agents confidently wrong.

​
The four interfaces, and when each is right

InterfaceWhen to useWhy
CLI (via the agent’s Bash/terminal tool)Default for coding agentsText output, low context cost, composable
TypeScript SDKGenerating app codeTypes and JSDoc become inline docs in IDE
MCP serverNon-shell agent runtimesUseful where shell access is unavailable
REST APIDirect integrations, non-agent clientsFlexible for production services
The same tool and action IDs back the interfaces where that surface is enabled.

​
Why we recommend the CLI for coding agents

For Deepline:
  • The CLI adds no Deepline tool schemas to the agent context. Claude Code, Codex, Cursor, Gemini CLI, Antigravity, Hermes, and most coding agents already know how to use a shell.
  • Output is text. Composable with awk, jq, grep, and downstream Deepline commands.
  • Failures are observable. Stderr messages are directly readable by the agent.
  • The same command can move from a local laptop to a repo agent, background agent, or sandbox.
MCP can still be the right interface for environments that cannot shell out, or when the host wants a protocol-level tool registry. We keep the CLI as the default because GTM data work is usually file-oriented: read a CSV, run a tool, write a CSV, inspect output, then continue.

​
Coding agents Deepline supports

Claude Code

Best-covered path today: Deepline skill plus CLI.

Codex

Hosted Deepline skills and CLI commands from the Codex terminal.

Cursor, Gemini CLI, Antigravity

Supported hosted skill targets with the same CLI command surface.

Hermes Agent / Hermes IDE

CLI-compatible today. Deepline does not publish a hosted Hermes skill target yet.
See Coding Agents for install commands, supported skill targets, and the Deepline GTM agent repo.

​
What we DON’T do (and why)

​
We don’t ship a Claude Code skill that wraps the CLI in MCP-style tool definitions

The skill teaches Claude Code about Deepline workflows; it doesn’t inject tool schemas into the context window. The agent still reaches the CLI via Bash. Token cost stays low.

​
We don’t auto-route to “better” providers without telling the agent

If you ask for apollo_people_search, you get Apollo. If Apollo is down, you get an error. Use a *_waterfall tool when you want failover.

​
We don’t hide pricing

Every tool has visible per-operation pricing. Agents reason about cost too. We expose it via deepline tools list (per-tool pricing in the output).

​
We don’t ship one giant deepline command with 200 flags

We ship narrow commands: enrich, tools search, tools execute, billing balance, auth status. Agents memorize a handful of commands; they don’t memorize 200 flags.

​
How this shows up in practice

A typical Claude Code session for an outbound campaign looks like: 
# Discover available tools (cost is shown per-tool in the listing)
deepline tools list

# Pilot on 5 rows to verify schema
deepline enrich --input leads.csv --output test.csv --name "email-pilot" --rows 0:4 \
  --with '{"alias":"email","tool":"name_and_domain_to_email_waterfall","payload":{"first_name":"{{first_name}}","last_name":"{{last_name}}","domain":"{{domain}}"}}'

# Run full file
deepline enrich --input leads.csv --output enriched.csv --name "email-full" \
  --with '{"alias":"email","tool":"name_and_domain_to_email_waterfall","payload":{"first_name":"{{first_name}}","last_name":"{{last_name}}","domain":"{{domain}}"}}'
Four commands. Plain text output. No JSON parsing. No MCP overhead. The total context spent on Deepline tool descriptions: zero. Compare to an MCP-first design where the agent would have spent thousands of tokens on tool schemas before composing the first command.

​
Further reading