Automation clients

DataMind Oda can serve a program of yours instead of a person: an Oda process speaks JSON-RPC over its standard input and output, and your program drives the sessions through it. Use it when a script or another tool of yours should drive Oda without the chat window.

Ways to serve a client

• The automation profile (acp). It serves automation clients that speak the Agent Client Protocol: your client initializes the connection, drives sessions, and closes them. The process runs until the client disconnects.
• The SDK profile (sdk). It serves Oda SDK clients. An SDK client starts a runtime of its own and talks to it over standard input and output; the SDK pages start at Oda SDK overview.
• The minimal runtime (sdk-minimal). A small standalone runtime with one model adapter and a single shell tool; it is described below.

How a serving profile is started, with its flags and one-off tasks, is in Command line. To run the Oda interface in a browser instead, see Oda in the browser.

Drive a session from an automation client

1. Initialize the connection from your client.
2. Create a session. Give it an absolute working folder, so both sides agree on where the work happens. When the session needs the tools of other services, add MCP server declarations, over standard input and output or over HTTP.
3. Choose the model for the session: pick one Oda advertises, or set a reasoning effort.
4. Send prompts, and read the updates your client receives while the session works.
5. Close the session with session/close.

• Another process can use session/list and session/resume against the same stored sessions. A resume reconnects the MCP servers its request declares; it does not replay the earlier conversation.
• When your client closes standard input, the process shuts down cleanly.
• MCP servers give a session the tools of other services, and are declared when the session is created; Memory, skills and connectors covers how they work in Oda.

Rules of the serving modes

• --help starts no server. The --help flag prints a profile's help and exits, and leaves standard input and output untouched.
• One client per process. A serving runtime works with one client, and runs until that client disconnects. Give each client its own process.
• Only the advertised surface. A serving mode adds no private methods or fields; clients use only what its protocol advertises.
• Standard output is for the protocol. The stream carries only protocol messages, and your client reads every byte of it. Keep anything else off it: a patch or plugin that prints there breaks the connection.
• Configuration changes need a restart. A running connection never observes a replaced server; stop the process, change the configuration, and start it again.

The minimal runtime

The minimal runtime (sdk-minimal) is a small standalone runtime, meant for an SDK client that needs exactly that: one model adapter and a single tool, a persistent shell (bash on macOS and Linux, pwsh on Windows). It deliberately leaves out the shared services of the other modes: there are no settings pages, no managed credentials, no telemetry, no compaction, no filesystem tools, no workspace instructions, no skills, no jobs and no subagents. It stores sessions as plain JSON lines under the Oda home folder.

• The model comes only from the client's initialization request, which overrides environment defaults.
• The context window falls back to about 1,000,000 tokens, and a launch setting changes it.
• The system prompt is a short coding-assistant persona by default, and a launch setting replaces it.

Settings for SDK deployments

• Token-limit stops. A deployment setting decides whether a run that stops at its token limit counts as accepted or as an error.
• Bundled Python runtime. The SDK profile ships a bundled Python runtime for its Office document features. A deployment setting replaces it; setting it to an empty value turns the bundled runtime features off.

Questions, answered

What is the difference between an automation client and an SDK client?

Both drive Oda over standard input and output. An automation client speaks the Agent Client Protocol to the automation profile; an SDK client uses the Oda SDK, which starts a runtime of its own and speaks the SDK messages. Pick the one your tool already speaks.

What happens to a session when the client disconnects?

Closing standard input shuts the process down cleanly. The sessions are kept, and another process can use session/list and session/resume against them; a resume reconnects the MCP servers its request declares, and it does not replay the earlier conversation.

Can I change the configuration while a client is connected?

No. A running connection never observes a replaced server, so configuration changes need a restart: stop the process, change the configuration, and start it again.

Can I add my own logging to a serving process?

Keep it off standard output. That stream carries only protocol messages, and your client reads every byte of it; a patch or plugin that prints there breaks the connection. Write your own output to a file, or log on the client's side.

Is the minimal runtime safe to point at a folder I care about?

No. It runs with full access, with no sandbox limits and no approval prompts, so its shell can change any path the process can reach. Use it only with an isolated workspace.

Which model does the minimal runtime use?

The one your client asks for in its initialization request. That request is the only model selection, and it overrides environment defaults.

What can I set when I launch the minimal runtime?

The context window, about 1,000,000 tokens by default, and the system prompt. The SDK profile's own settings, such as token-limit handling and the bundled Python runtime, are for deployments.

Does the minimal runtime include my usual tools and skills?

No. It is deliberately small: one model adapter and a single shell tool, with no skills, no filesystem tools, no workspace instructions, no subagents and no settings pages. Choose the SDK profile when you need the usual tool set.