Skip to main content
Overmind’s workflows span your coding environment and the platform. The coding agent interprets the task, reads source material, writes code and explains the evidence. Overmind retains data and recipes, executes supported operations and records their outcomes.

​
How one request becomes a workflow

A user request describes the outcome and constraints. The coding agent discovers the connected project, reads tool schemas and resources, resolves the relevant data, and carries out the dependent operations. It can write a preparation package locally, publish it through MCP, inspect the resulting cell and use that exact cell in the next step—all in one conversation. The agent returns evidence you can review: what it changed, the saved data or run, measured results and remaining decisions. A prompt can start a long-running job; the job continues on the platform even when the chat disconnects. In a later conversation, supply its link and ask the agent to inspect or continue it. A plain-language prompt in these docs is a request to your coding agent. A native MCP prompt, such as author-dataset-transformation, is a named workflow supplied by the server. Clients expose those prompts differently; ordinary chat requests work without memorising slash commands. The agent can use a native prompt where supported and follow the connected tools and resources otherwise.

​
Four interfaces, one project

MCP is a first-class platform interface sharing domain services with REST and the Console. A plugin can package its connection and skills, but the connected tool catalogue supplies the current contract. Installed prose can lag a deployment. Initial account login, credential entry and client permission grants still use the host’s supported flows. Membership or billing controls without an MCP operation remain in their management surface. The agent should name the required action when it reaches one. Local filesystem work stays in the coding environment. MCP does not upload a local file simply because the agent knows its path; the CLI transfers its bytes with a separately verified connection.

​
Starting with data

A project can begin with a brief and source files. There is no need to invent a repository, capability or trace history. The useful chain is a retained source, an explicit preparation, exact consumer inputs and a measured result. Data Workshop has no platform chat agent. Landing does not start semantic preparation. A coding agent authors a retained Python package; the isolated runtime executes it and publishes cells. Semantic conclusions remain attributable to the evidence and authoring work that support them.

​
Starting with an application

A local scan describes the application’s capabilities and source structure. Traces describe observed executions. Evaluations relate those observations or controlled outputs to explicit checks. An optimiser runs candidate application changes in the local environment; model training executes through the configured provider. These paths can meet: traces can become source data, and data-first models can later serve an application. Neither path requires pretending that source data or model outputs are verified answers.

​
Boundaries that matter

A deployment address identifies where the platform request goes, not where all compute runs. A local server can use remote model and GPU providers. The coding agent also has its own model provider and funding. A job receipt makes asynchronous work recoverable across chats and disconnects. It records what was requested, what ran and what remains unknown. This is why a reconnecting agent should inspect existing work before deciding to submit more.