Skip to main content
Read this page once and the rest of the product clicks into place. Adopt is built on a small set of objects, and almost everything you’ll do maps onto them.

The core idea: separate “who” from “what”

Two independent questions run through everything in Adopt:
  • Who does the data belong to? — a specific client. This is the isolation boundary.
  • What is being done to it? — a process, like R&D tax credit or transfer pricing.
Keeping these separate is what lets one client have several processes without their data getting tangled. The objects below map onto those two axes.

The objects, top to bottom

  • Customer — your firm or organization (the accounting firm itself).
  • Workstream — one client of yours. This is the isolation boundary: files, data, and access are scoped here, and a member with access to one workstream can never see another’s data. On the end-user surface this is simply called a Client.
  • Engagement — one process for that client (R&D Tax Credit, Transfer Pricing, Close). Each engagement has its own agent, files, review queue, and retention. A single client can have several engagements running side by side.
  • Run — one execution of the work (this quarter’s R&D workpaper for this client).
  • Output — what a run produced. It waits in the review queue until a person approves it.

Supporting objects

  • Doc Store — where a client’s files live (the File Explorer). Populated by connecting a source and syncing. End users just call these “files.”
  • Data Store — optional structured tables an agent can query (e.g. a client-management table), scoped the same two ways as everything else.
  • Agent — the thing that does the work. It carries instructions and skills. Naming an agent provisions a Space behind the scenes.
  • Space — an isolated bucket for an agent’s data. Provisioned automatically; you rarely manage it directly.
  • Skill — a capability an agent can use: read documents, query the Data Store, generate a workpaper, search the web, fill tax forms.
  • HITL review gate — the checkpoint where prepared output waits for human approval.

Two vocabularies, same objects

The end-user surface uses finance words; the builder surface uses platform words. They describe the same underlying objects.

Why the Engagement layer matters

If a client only ever runs one process, Workstream and Engagement look like the same thing. The moment a client needs two processes — say R&D and transfer pricing — the Engagement layer keeps them separate (different agents, different review queues, different retention) while still linked under one client. Reviewers, retention clocks, and audit trails all attach at the engagement level.

Next steps

  1. Workstreams and Engagements
  2. Doc Stores and Data Stores
  3. Human-in-the-loop review