What is Deepline?

Deepline is where a coding agent turns a GTM process into code you can run, inspect, and reuse. Use it to enrich a list, research accounts, react to a supported event, or send an approved result to the systems your team uses. The product has three primitives: Plays run code, Monitors receive supported external events, and the Database keeps durable records between runs.

​

The three primitives

Plays execute code. Monitors ingest external events. The Database stores the records both use. These are distinct responsibilities, which keeps an event feed from becoming hidden business logic and keeps one run’s temporary output from becoming permanent customer data by accident.

​

How the system fits together

For an event-driven workflow, the path is: External source → Monitor → Database → Play → destination The Monitor receives an event and writes the accepted row. A published Play listens for matching Database rows, runs its code, and can write an approved outcome to a CRM, sequencer, warehouse, or another system. Not every Play starts from a Monitor. You can also start one manually, from the CLI or SDK, through an API call or webhook, or on a schedule. A Monitor is the right path when a supported source produces ongoing events that should become durable data before code reacts to them.

​

Access layers are not primitives

Skills, the CLI, the SDK, MCP, and the Claude plugin are ways for people and agents to work with the same Plays, Monitors, and Database. They do not create a separate workflow model or a fourth kind of stored data.

• A skill gives a coding agent instructions and product context.
• An interface lets a person or agent call Deepline: a terminal, SDK, MCP client, or Claude plugin.
• A primitive is a product object that runs code, receives events, or stores durable records.

​

Choose an interface

Run your first Play.