The difference between a chatbot and an agent
A chatbot produces text for a person to act on. An agent produces actions: it queries the CRM, matches the invoice, drafts the order, sends the digest. That is what makes it useful for operations, and it is also what makes governance the first question rather than the last. An agent that can create a record can create the wrong record.
tacitrun treats that as a runtime problem, not a prompt problem. Reads are free; every write to a real system is intercepted at the call and held for a person, so an agent can be given real work without being given unsupervised authority.
What an operations team actually gets
The work that lives between applications: re-keying, reconciling, routing, counting, chasing. A domain agent takes one such step from a mapped process, runs it on the real systems, and hands the result, or the write it wants to make, to a person. The team keeps the decisions and loses the swivel-chair.
Because the agents are built from the team’s own procedure rather than a vendor template, the process itself becomes the specification: the rules it carries are the rules the agent is tested against and the rules the runtime enforces.
The terms, as the product defines them
- Domain Agent
An AI agent built from a process step, scoped to one job.
An AI agent generated from a process. It is scoped to one part of the workflow, knows the relevant policies (from your corpus), can use the tools it needs, and is tested before it ever acts. A domain agent starts by drafting decisions for a human and only earns the right to act on its own after it agrees with your team often enough in shadow mode.
- Automation
A "when this happens, do that" that runs itself by fixed rules.
A straightforward, deterministic flow — "when an invoice is 30 days overdue, send the reminder" — that runs on a trigger and follows fixed rules with little or no judgment. You still create it just by describing it; Tacitrun keeps it simple under the hood. (Webhook/event and manual runs work today; time-based schedules are rolling out.)
- Assistant mode
A way to run an agent: it drafts, you decide.
A run mode for an agent — you run it or talk to it for a task, and it checks with you on anything important before acting. The opposite of running autonomously (where it acts on its own on a trigger). Every agent can run either way; you move it from assistant mode to autonomous as you build trust.
Questions people ask about this
- What can a Gmail (Google Workspace) domain agent actually do?
- Once Google Workspace is connected, a domain agent can: search/list messages with the normal Gmail search syntax (e.g. "category:promotions newer_than:7d"), read a message, list labels, archive or label messages (single or up to 1000 at once), move a message to Trash, and send email. Archive means removing the INBOX label — the message stays searchable, it just leaves the inbox. These are grounded in the Gmail API, not simulated. Two notes: (1) it needs the gmail.modify scope, so if you connected Google Workspace before this was added, reconnect it (Tacit re-prompts consent). (2) To run automatically on incoming mail today, use a scheduled domain agent that searches recent messages and archives/labels them — a true "new email" push trigger is on the roadmap, not yet available.
- What’s the difference between a process and a domain agent?
- A process is the workflow blueprint (a graph of steps). A domain agent is an AI agent built from part of that process to actually run it.
- Will a domain agent act without my approval?
- No — not by default. A new domain agent only drafts decisions for a human. It can act on its own only after it proves itself in shadow and a human promotes it.
- What does “earn autonomy” mean?
- A domain agent must agree with your team on real cases (default 90%) in shadow mode before it’s allowed to act autonomously. Trust is proven, not assumed.
- In what order do I do this — build, evals, submit, connect, go live, autonomy?
- The business builds and validates; IT connects and approves — a clean handoff. The order: (1) BUSINESS builds the agents and runs evals (≥80% pass) — that’s all it takes to submit; you do NOT need tools connected first. (2) BUSINESS clicks “Submit the whole process for IT review”. (3) IT picks it up: connects the required tools and binds the API fields in Integrations. (4) IT approves — approval is the go-live gate, so it can’t approve until the tools are connected, and nothing ever runs unconnected. (5) It deploys live in domain agent mode. Then the domain agent trial / agreement begins: it works alongside a human who approves each draft in the queue, and earns the right to act UNATTENDED once it agrees with real human decisions ≥90% over ≥10 real cases. IMPORTANT: the “domain agent trial” agreement is NOT a pre-launch step — the platform never fakes “what a human decided,” so the score stays empty until it’s live and people review its drafts. Two separate gates: Evals + IT approval (with tools connected) make it LIVE (human-in-the-loop); agreement with real decisions earns AUTONOMY (unattended).
Related
See it on one of your own processes. Free for the whole product for a trial period, no card needed to start, every write held for your approval.