Glossary

An isolation boundary that controls which agents can retrieve which knowledge.

A named boundary (e.g. "hr", "engineering", "finance") on a piece of knowledge. By default an agent sees only tenant-wide knowledge; on the Knowledge & Context → Knowledge tab you tag a document with a scope (the inline scope chip) and grant that scope per agent (the "Who can see scoped knowledge" panel on the same tab), and the agent can then also retrieve that scope's documents. Enforced in the retrieval tools — so sensitive data (HR, Engineering) stays strictly isolated, and even a multi-hop answer can't cross a boundary. Empty grants mean tenant-wide only (default-deny for scoped content).

Start from a ready-made domain agent and tweak it to your team.

Instead of starting from a blank page, pick a pre-built domain agent for your function (e.g. a Forecast roll-up for Revenue ops) and adjust it to how your team actually works. A copy is made just for your team and stays inside your company's workspace.

An AI helper you build for a specific part of your work.

The everyday name for an AI helper built from the way you described your work. It does the work using your data and connected systems. You run it in assistant mode — it drafts, you decide — or let it run autonomously on a schedule or trigger, with the human oversight you choose. "Domain agent" because it's scoped to your specific process, not a general chatbot.

How often your team accepts an agent’s proposal, on real decisions.

Every time an agent proposes a change and a person accepts, changes, or stops it, we record whether the agent got it right. Agreement is the share it got right — measured on real work, not a test. It is the number that decides autonomy: an agent must match your team on 90% of real decisions before it is allowed to act without asking. A low agreement figure is not a fault to hide; it is the agent still earning trust, and it climbs as your team corrects it. Where an agent has too few decisions to judge, we say so rather than showing a percentage that would mislead.

Getting something signed, chased, or cancelled — and reading the result back.

An agreement workflow is the part of a process that runs through a signature platform such as DocuSign: send an agreement for signature, see who has not responded, chase them, void one that has been superseded, and read back what was signed or what a signer typed in. A domain agent can own the whole loop, and every action that changes an agreement — sending, chasing, voiding — goes to your approval queue before it happens. Agents work with agreements and templates that already exist; they do not create templates or invent fields in your signature platform.

Hand a setup step (like connecting a system) to your IT team.

When an agent needs access to a system you don't have the login for, choosing "Ask IT" sends the setup step to your IT team (it lands in their Inbox and notifies them). Your agent waits on that step and you're told when it's ready — no technical work for you.

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.

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.)

Your team’s fully-loaded $/hr — the one number every domain agent’s ROI is figured from.

To show what a domain agent is worth, we multiply the tasks it handles per month by the minutes a person spends per task, then by your team’s blended, fully-loaded hourly rate (salary + benefits + overhead). Tasks/mo is the domain agent’s real production throughput once it’s live (last 30 days), and a conservative editable estimate before go-live — never the pricing bundle’s run allowance. Minutes-per-task starts from the domain agent’s steps but you can override it per domain agent (effort varies by use case) and it sticks across versions. The rate defaults to a sensible anchor for your industry, and you can override it once — in onboarding or Settings → Value rate — so every domain agent’s ROI across the whole workspace uses the same number. It’s only used for the value story; it is never billed and never shared outside your workspace.

A pre-built process template to start from.

A ready-made process you can pick to seed a new process instead of starting from a blank page. Pick your industry to see its processes grouped into Front office (customer-facing & operational), Digital (e-commerce & self-service), and Standardized (the finance / HR / IT / procurement / legal back-office every company runs). With "All industries" you browse the whole library by scope (cross-industry foundations, value chains, industry packs).

Enterprise plan: the platform’s model calls run on Claude models in Vertex AI Model Garden inside your own GCP project — or on your own OpenAI / Azure OpenAI key (GPT-5.6 Sol, GPT-5.6 Terra, GPT-6 Astra).

With Bring your own model, the platform’s model calls for your workspace — composing domain agents, on-demand runs, evaluations, chat, and reading uploaded images and documents — are sent to Vertex AI in your own Google Cloud project, using the Claude models (Claude Opus 5, Claude Sonnet 4.6) you have enabled in Vertex AI Model Garden; knowledge embeddings run on Google’s embedding models in your project as well. Tacit authenticates as your service account through Workload Identity Federation, so no Anthropic API key is involved and no key is stored with us. Google bills the usage to your project, and your project’s IAM, audit logs and data-governance controls (region, VPC Service Controls, CMEK) apply. The Tacit application itself still runs in Tacit’s cloud — it builds the prompt and receives the answer; only model inference moves into your project. Domain agents deployed into your project (Cloud deployment → Run deployed agents in your project) make their model calls on Claude models on your Vertex AI as well. Enterprise workspaces can alternatively bring their own OpenAI or Azure OpenAI key for GPT-5.6 Sol, GPT-5.6 Terra or GPT-6 Astra: the key is stored encrypted in Tacit’s vault and used only for that workspace; web search is not available on those models. Available on the Enterprise plan; configured by an owner under Settings → Bring your own model.

Always-available platform capabilities a domain agent can use — no connection needed.

A small set of capabilities every domain agent can call without any setup or credentials: search_knowledge (retrieve from your Knowledge & Context), lookup_term (resolve a company term/acronym from the glossary), graph_query (traverse your knowledge graph), read_document (read an attached file → text), and the chart/spreadsheet generators. On a domain agent’s Required tools panel these show a blue “built-in” badge — they are NOT catalog connectors, so “built-in” means ready to use, not missing. Only external systems (Salesforce, Slack, …) need connecting. The rule guard — the check that runs before every write against your critical rules — may use the same knowledge reads, plus the read operations of the agent’s connected systems, for one lookup when a rule depends on a fact; it never uses web search. You see each lookup in the run trace as “guard.lookup” under “guard.rules”, with whether it found anything. The guard is also shown the decision rules of the process-graph steps your critical rules refer to — the same steps the check card quotes — so a default your process states (a threshold to use when none is supplied, say) counts as a fact when it judges a write.

Your company's terms, acronyms, and what they mean here.

A curated list of the words your business actually uses — "PO = Purchase Order (not Project Order)", "1st shift = 06:00–14:30" — each with a definition, optional acronym, and synonyms. Agents resolve company jargon through it via the built-in lookup_term tool, so they interpret terms the way your team does. It fills itself: every document you add to Knowledge & Context is auto-mined for candidate terms (drafts, grounded in the doc), and the Glossary tab shows "Terms your agents asked about" — words agents looked up at runtime that you haven't defined yet — so the glossary learns from real usage. IT approves each candidate before agents use it; you can also add terms by hand. Managed on the Glossary tab of Knowledge & Context.

Turn your description into a structured process graph.

When you compile, Tacit reads everything you described or uploaded and produces a structured graph (the BPMN diagram) — the steps, the order, the decision points. A "critic" pass then flags gaps (missing steps, unclear rules) for you to resolve.

An enterprise document store you pull into the knowledge layer.

A connected document repository — SharePoint, Confluence, OneDrive, or Google Drive — added on the Knowledge & Context → Sources tab by pasting a link to a site, space, or folder (the provider and scope are detected automatically — no dropdowns). Adding it lists the documents in scope, extracts and chunks them, embeds them, and adds them as approved tenant-wide knowledge (content-hash-deduped, tagged with any access scope you set). Connect the source on Integrations first (OAuth); without credentials a pull returns sample documents so you can see the flow. Scheduled, incremental sync lands with the cron infrastructure.

A compact always-on brief about your business, baked into every agent run.

A small, high-signal block — your tenant profile (what the business does, functions, compliance) plus the most relevant glossary terms — injected into each agent's instructions at runtime as reference (never as commands; your rules always take precedence). It keeps base prompts lean while everything else stays available on demand through the knowledge tools. Assembled automatically from Knowledge & Context; you don't maintain it directly.

Summarize old turns on long runs instead of hitting the context limit.

A runtime-oversight dial. off (default) = a very long run that approaches the model's context limit fails rather than summarize. summarize_oldest = fold the oldest turns into a running summary and keep recent turns verbatim, so long sessions continue. summarize_by_topic = group prior turns by topic and summarize each, preserving more cross-topic detail at slightly higher cost.

Your business's knowledge that grounds the domain agents.

The documents, SOPs, screenshots, pasted notes, and chat context you give Tacit. The corpus is how a domain agent knows your specific rules ('refunds over $2k need a manager'). It's referenced when composing prompts and when grading evals.

Where domain agents send decisions for a human to approve.

When a domain agent isn't fully autonomous (or hits a high-risk action), it routes the decision to the queue. A human accepts, modifies, or rejects it. Those corrections feed back in as learning signals.

A live, running instance of a promoted domain agent.

A promoted domain agent deployed to a runtime (Tacit-hosted by default, or your own cloud). It exposes an endpoint that can be invoked by the UI, an API call, or a webhook.

A staffing domain agent that handles back-office admin beside your human workforce.

In the staffing vertical, a “digital worker” is a domain agent that automates the admin AROUND your placed workforce — recruiting, scheduling, onboarding, timekeeping, HR Q&A, safety/compliance, reporting — not the physical labor itself. It drafts and proposes; risky actions (texting a candidate, booking a shift, editing a timecard, sending a notice) always wait for a human OK.

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.

A domain agent acts on its own only after it proves it agrees with you.

The core safety idea: nothing acts autonomously by default. A domain agent drafts → is reviewed → shadows → and only then, with evidence and a human approval, earns the right to act. Trust is earned, not assumed.

An automated test that checks a domain agent makes good decisions.

A suite of test cases — real-ish inputs with expected outcomes derived from your process and corpus — run against a domain agent. Each case is graded (pass/fail) so you can see, with real numbers, whether the domain agent is reliable before it goes live.

The specific pieces of data a domain agent can read and write in a connected system.

Every connection has a set of fields — e.g. a Salesforce contact’s email, an order’s total. Open “Fields” on an Integration to see, in plain language, what a domain agent can read versus write. Connect the platform and click “Refresh from your live system” to also detect your own custom fields (per object, e.g. Lead vs Contact). On a domain agent’s bindings step you CHOOSE exactly which fields that domain agent reads and writes — the list is drafted from a live API describe of the object, so these are the real fields. Once you confirm a binding, least-privilege enforcement is ON by default: the runtime strips any read or write field outside the approved allow-list before the call reaches the system, so the domain agent cannot touch a field IT didn’t approve. A domain agent with no confirmed bindings is unaffected (no restriction). You can opt a specific domain agent out via the field-selections API if needed. Some systems also have a fixed “destination” to pin — e.g. which Slack channel notifications go to. The binding card shows a live picker (pulled from your connection) under “Destination — pinned for this domain agent”; the value you pick is always used at runtime, so the domain agent can’t post anywhere else. Some systems are reached over MCP rather than a REST API. The binding card works the same way, with one difference: you first pick the ACTION the binding governs (MCP’s unit of access is the action; the object is one of its inputs), then the object, then pull the fields. The field list comes from that system’s own field-listing tool, verified once by actually calling it and then remembered for every later binding. You never type a field name by hand in either case — if a system’s fields can’t be determined, the binding says so and stays with IT rather than pretending to be scoped.

The visual map of a process — steps and how they connect.

The diagram of your process: boxes (steps) connected by arrows (flow), branching on conditions. Steps are color-coded by who does them (human / system / domain agent / hybrid). You can edit the graph directly on the canvas.

A proposed domain agent upgrade, mined from real signals.

Tacit watches every run (human corrections, eval failures, escalations), and when a pattern is well-corroborated it proposes a concrete improvement. The proposal is tested against the current version and only goes live after you approve it. Nothing changes on its own.

A connected platform, authorized with your own credentials.

A platform you've connected by registering your own OAuth app and pasting its credentials. Tacit encrypts them, refreshes tokens, and never holds admin access to your systems.

The control layer: who can approve what a domain agent does.

Compliance tags (e.g. SOX, GDPR), approval policies, and an audit trail. IT/security review and approve domain agents before production, set policies that auto-gate risky capabilities, and can see exactly what changed and why.

The governed context layer your agents reason against.

The single place where your company's knowledge and context live — documents, a business glossary, your systems of record, and who can use what. IT curates it; business users contribute their team's knowledge to it. Agents draw on it at runtime (a small always-on "context card" plus on-demand lookups) so they speak your company's language, route to the right system, and cite your policies — grounded in your reality, never hardcoded. It is retrieval + structured context, not model training on your data.

Your documents turned into linked entities + relationships for multi-hop answers.

A per-tenant graph of the entities in your business — systems, people, teams, products, policies, processes, terms — and how they relate, extracted from your documents and linked to your glossary + processes. Agents traverse it with the graph_query tool (GraphRAG) to answer relationship and multi-hop questions a plain search can't — e.g. "who owns the system that books invoices for the EU returns process?" graph_query is HYBRID: it returns graph facts (the connections) + supporting passages (the evidence text) + relevant themes (cluster summaries for big-picture questions) in one answer. Built + explored on the Knowledge & Context → Knowledge graph tab — an interactive view you can pan, zoom, and click to walk node-by-node. Access-scope-gated, so a traversal can never cross an isolation boundary. Conversations (Slack) come in a later phase.

A live domain agent is frozen under its IT approval until you unlock it.

When a domain agent version is approved by IT and goes to production, its spec is Locked (a padlock badge) — frozen so what IT signed off on can’t silently change. While locked, you can’t edit or recompose it, and "Update this process" skips it. To change it, open the domain agent and click Unlock for editing (owner/editor only): that marks the current approval as superseded and takes the agent out of production (it becomes editable and its live runs stop) until it’s re-checked and re-approved. So the normal edit cycle for a live agent is: Unlock → recompose/edit → re-run checks → submit for IT approval → back to production.

A standard way for a system to advertise the tools it offers an agent.

MCP (Model Context Protocol) is an open standard a system can use to describe what an agent may do with it — each tool with a name, a description and an argument schema. Because the server describes itself, connecting one does not require us to write a connector for it: Tacit asks the server what it offers and you choose which of those tools this workspace may use. You can connect your own MCP server from Integrations → Custom apps. Tools that change data are treated as writes and go to the approval queue like any other write, and a tool is only treated as read-only when the server itself says so.

What a domain agent remembers across a session and across runs.

Governed by each domain agent's memory policy: session (remembers the current conversation), persistent (accumulates durable facts), or RAG (semantically recalls similar past decisions). Grounded in your data and redacted.

Where your agents ask you to approve, change, or stop something.

Your inbox of decisions an agent has paused on before acting — each shows what it wants to do and why, in plain words. You can approve it, use your own choice instead, or stop it. Risky actions (like sending a message or moving money) always wait here for a human.

Make a domain agent draft a step plan before it acts — and hold off-plan actions.

A runtime-oversight dial. off (default) = the domain agent acts directly. shadow_only = it drafts a step-by-step plan during Shadow/Eval runs so you can review its intended approach without slowing production. always = it plans before every run and the runtime tracks deviations; in production, any off-plan tool call is held in the Decision queue for human review before it can run.

A workflow, mapped as a step-by-step graph.

A business workflow — like vendor onboarding, invoice approval, or returns intake — captured as a graph of steps (a BPMN-style diagram). Each step is done by a person, a system, or a domain agent. A process is the blueprint; domain agents are what run parts of it.

Move a verified domain agent to production so it can run.

Promotion makes a domain agent version the live, production one. It requires passing evals + shadow and a governance/IT approval. Promotion is append-only and reversible — you can always roll back to a previous version.

Documents + outcomes your domain agents produce — downloadable in the workspace (formerly "Generated files").

When a domain agent produces a spreadsheet, PDF, chart, or other document, it appears on the Results page with a download link, labeled with which domain agent made it as part of which process. (Business and IT now see the same "Results" name.) Files are kept for download for 30 days; optionally connect Box / OneDrive / SharePoint / Google Drive on a process to also save a permanent copy in your own storage.

Take a domain agent or a whole process out of active use (reversibly).

Retiring removes a domain agent from your active list and — if it was live — tears down its running service so it stops working and can’t bill. Retiring a PROCESS also cascade-retires all of its domain agents in one step. It’s a soft action: nothing is permanently deleted; the item stays as read-only history and can be Restored later (a domain agent comes back as a draft to re-validate; restoring a process reactivates the process but leaves its domain agents retired, so restore any you still want individually). Every retire/restore is audited and needs editor (or owner) permission — available in both the business and IT views. Distinct from the automatic "retired · superseded" state a domain agent enters when a newer version replaces it.

Operational dials (plan mode, context compaction) you can change without re-promoting.

Two governance dials on a domain agent's Spec tab, separate from its behavior contract. Because they tune oversight rather than behavior, saving them does NOT bump the version and is allowed even on a locked production domain agent — so you can tighten or loosen the leash on a live domain agent without a fresh IT approval. Changes apply to in-app runs (Test, Shadow, Eval) immediately; deployed domain agents pick them up on their next deploy.

The domain agent runs alongside humans without acting, to prove itself.

In shadow, the domain agent proposes what it would do on real cases while a human makes the actual call. Tacit measures how often they agree. A domain agent must reach a high agreement bar (default 90%) before it can be promoted to act on its own.

A reusable, IT-approved knowledge pack a domain agent can pull in.

A curated bundle of know-how (a decision table, a playbook) that domain agents load on demand when the situation matches. Skills are tenant-private and versioned.

The staffing ATS / payroll system the staffing domain agents work in.

TempWorks is the system of record many staffing firms run on (candidates, job orders, assignments, timecards). For staffing workspaces, the staffing domain agents connect to it to read orders/applicants and — only after your approval — write messages, assignments, timecard corrections, and notices. Every write goes through the approval queue. In a pilot you can run on seeded sample data first and connect the real TempWorks later.

An auto-clustered group of related graph entities with a plain-English summary.

The knowledge graph is clustered into themes — groups of densely-connected entities (e.g. everything around billing: the billing system, AR team, dunning policy, invoice process). Each theme gets a short LLM summary. Themes answer global / big-picture questions a single lookup can't — "what are the recurring problems in returns?", "summarize how billing works" — by pointing the agent at the right cluster instead of one passage. Rebuilt with the knowledge graph; each theme inherits the most restrictive scope of its members, so a sensitive theme stays isolated.

A capability that lets a domain agent read or act in another system.

A connector to a system of record (Salesforce, SAP, Slack, ServiceNow, Snowflake, …). A domain agent only gets the tools it needs, calls them through a governed proxy, and never sees the raw credentials.

The detailed record of what happened inside one run.

Every invocation produces a trace made of spans — each LLM call, tool call, eval, retrieval, and learning step — with cost, latency, and status. Visible in Observability, the Console, and the trace view.

The work your agents handled this month, in money — after what you pay.

We price a process at a fraction of what it delivers, so value delivered is what you keep: the labour the agents took off your team (hours handled × a loaded rate for your industry) plus any outcome value you have affirmed, minus the price of the process. It is the same figure your billing page uses — Performance and billing read one source, so they cannot tell you two different things. Before an agent has enough live runs, the figure is an estimate from how the process is set up, and it is labelled as one.

The standardized + front-office blueprints, mapped to PE value levers.

For private equity: the cross-portfolio set of repeatable processes — working capital/cash, cost/margin, revenue/commercial (front office), customer/service, and shared services — that deploy identically across every portfolio company. It is the Standardized + Front office + Digital blueprint layers, framed as the value-creation plan. We automate the repeatable-process scope (not ERP re-platforming, data-platform builds, or cloud migration).

A signed URL that lets another system trigger a domain agent.

A stable, HMAC-signed endpoint for an external system (Salesforce, SAP, a queue) to fire a domain agent when an event happens. The signature is the auth — no login needed.

Google’s keyless way to let Tacit act inside your GCP project — no service-account key is ever created or shared.

Workload Identity Federation lets an identity outside your Google Cloud project act inside it without a key. You create a pool in your project that trusts Tacit’s runtime identity (project tacitapp-496401), a service account in your project with only the roles it needs, and allow the pool to impersonate that account. At call time Tacit presents its own short-lived Google token and Google exchanges it for a short-lived token as your service account — minutes of validity, nothing stored. You can cut access instantly by removing the pool binding, and every call appears in your project’s audit logs as your service account. The same trust relationship powers both deploying domain agents into your project (Cloud deployment, Pattern 2) and Bring your own model.