> ## 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.

# What is Deepline?

> Deepline lets coding agents build, run, and inspect repeatable GTM work.

Deepline lets a coding agent turn a GTM process into executable code, then run
and inspect that code outside the agent's conversation. The distinction matters
when a useful experiment becomes recurring work: the next execution needs a
known input, an identifiable version, and an outcome someone can explain.

The system separates three responsibilities. **Plays** execute business logic.
**Monitors** ingest supported external events. The **Database** keeps customer
records that need to outlive an individual run. Understanding those boundaries
makes it easier to choose where a rule or record belongs.

## A workflow has more than one kind of state

Consider a team that wants to react when a target account posts a relevant job.
The job posting is evidence from an external source. Whether the account is in
territory is the team's policy. Whether an alert reached a rep is an operational
outcome. Those are different facts, even though one workflow connects them.

A supported Monitor receives the event and writes an accepted row into a
Database stream. A published Play with a matching SQL listener receives a row
change, evaluates the account, and can call an appropriate destination tool.
The Database can retain customer-owned research or decisions for later use.

![External events enter the Database through Monitors. Plays act on data and send results to downstream systems.](https://mintcdn.com/deepline2/jbNrWuL_F2rDi05A/images/deepline-system-architecture.svg?fit=max\&auto=format\&n=jbNrWuL_F2rDi05A\&q=85\&s=f01795928600545da30b3805dc4d5b6b)

A Monitor supplies events, the Database retains accepted rows, and a Play applies business logic.

The illustration shows a possible workflow, not a requirement to use every
component. A one-time account-research Play can start from a file without any
Monitor. A Monitor's stream can also be useful to a query or dashboard without
starting a Play.

## Plays turn a decision into something repeatable

A Play defines what happens to its input: the sources it consults, the criteria
it applies, and the result it returns. A published version gives that logic an
identity independent of the agent session that authored it. A run is one
execution, with its own input, status, and recorded work.

This separates changing the rule from applying the rule. Revising a draft does
not rewrite the logic of an already published version. A later investigation
can distinguish a bad input from a change in the business rule, instead of
trying to reconstruct a conversation.

Repeatability does not mean every execution produces an identical answer.
External records change, data providers can fail, and a workflow can choose to
refresh previously cached information. The useful guarantee is an inspectable
execution boundary, not certainty about the outside world.

## Monitors separate arriving data from reacting code

A Monitor represents a supported provider feed and its scope. It is not the
place to put lead-routing or qualification logic. Its accepted rows can serve
several consumers, each with a different purpose.

For the job-posting example, one Play might notify an account owner while
another uses the stream for a hiring-trend report. A different business rule
does not necessarily require another upstream subscription. The source scope
and each consumer's selection rule solve different problems.

## The Database carries memory across runs

Run outputs answer what happened during one execution. Durable customer tables
answer what the process needs to remember across executions: known accounts,
accepted signals, review decisions, or prior research.

Deepline also stores its own platform state, such as Play versions, Monitor
configuration, credentials, and billing. Those records are managed by the
product, not by customer SQL. Customer-owned working data and platform control
state have different ownership and access rules.

## Interfaces share the same underlying objects

The CLI, SDK, MCP, and supported agent integrations provide different access
paths. Skills supply instructions and context to an agent. They do not create a
second Play runtime or a separate kind of Monitor.

An agent can help author and submit a Play, then leave the conversation.
Accepted remote work does not require the agent to keep generating tokens.
The application still needs to observe the run's outcome; closing a client or
ending its wait does not establish completion or cancellation.

## Continue learning

* [How Plays work](https://deepline.com/docs/plays/plays-overview.md): versions, runs, checkpoints, and outcomes.
* [How Monitors work](https://deepline.com/docs/plays/monitors.md): source scope, shared streams, and listeners.
* [Where data lives](https://deepline.com/docs/data-lifecycle.md): files, run datasets, durable tables, and CRMs.
* [Run your first Play](https://deepline.com/docs/quickstart.md): the practical starting path.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.