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.
A Monitor supplies events, the Database retains accepted rows, and a Play applies business logic.
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: versions, runs, checkpoints, and outcomes.
- How Monitors work: source scope, shared streams, and listeners.
- Where data lives: files, run datasets, durable tables, and CRMs.
- Run your first Play: the practical starting path.