Studio Product · Studio

The platform configures the platform.

Studio is where Activity Plans, Task Templates, validations, and document models are authored. Agents draft the routine pieces from a use-case description. Your team edits the result, tests it against real documents, and binds it to the projects that need it. Configuration that used to need an engineer starts as a draft an analyst owns.

Where Plans get authored

A typed graph of steps. Visual debugging. Test runs against real documents.

The editor shows an Activity Plan as a graph of steps with declared inputs, outputs, and dependencies. Click a step to see what it does and where its inputs come from. Run the Plan against a sample document and watch the run light up step by step. Validate the inputs schema before you bind.

Studio · Activity Plans · AP-Intake-v3 · draft Real screen, anonymised
AP-Intake-v3 PlanSchemaTests
Save Validate Test on doc Bind →
Ingest doc → bytes
Classify type, confidence
Pull rules vendor → ruleset
Extract financial fields fields, exceptions[] Agent draft
Validate schema + rules
Create Task if low-conf
Post system of record

The "Agent draft" badge marks steps an agent proposed. They don't go live until a human approves and binds the Plan.

Agents in Studio

A use case in. A draft Plan out.

Tell Studio what process you're building — AP three-way match for a new line of business, financial spreading for a new accounting standard, claims intake for a new policy type — and the agents draft the routine pieces: the steps, the validations, the Task Templates, the test cases. Your team reviews, edits, fills in the judgment calls, and binds. The agents handle the mechanical work that used to fill the first half of a services engagement.

  • Agents work from your existing Activity Plans as patterns; they don't start from scratch.
  • Every agent draft lands in review. Nothing binds without a human approving.
  • The agents are the same ones that work exceptions in Workflow and propose rules in Knowledge. One model of agent, three surfaces.
What you author

Four authored objects. One typed graph.

Activity Plans

Compose Activity Plans as a typed graph of steps with declared inputs and outputs. The reusable definition of how an Activity runs.

Task Templates

Author Task Templates that match how your team works. Fields, statuses, ownership rules. Defined at the organisation level, bound to the projects that need them.

Validations

Declare the rules an Activity should check at each step. Attach validations to fields, to documents, to Activities, or to the workflow as a whole.

Document models

Define what a document looks like, what fields it carries, and how it varies. Reusable across the customers and vendors you handle inside your tenant.

Confidence before commit

Run the Plan against real documents. See where it lands.

Studio runs an Activity Plan in a sandbox before it binds to a project. Step-by-step debugging. Confidence scoring on extracted fields. Validation results visible inline. The Plan binds to a project only when it passes the test bar your team sets.

  • Dry-run a Plan against a folder of real documents.
  • Step-by-step inspection — pause, re-run from a step, see inputs and outputs.
  • Confidence scoring on every field; route low-confidence into a Task automatically.
  • Bind to projects when it's ready, not before.
Configuration without code
Activity Plans authored declaratively, not coded
Agent-drafted
Routine pieces drafted by agents, reviewed by humans
Test before bind
Validate against real documents before going live
The platform can't do anything your team couldn't do. Agents draft; humans bind.

See Studio on a Plan you'd ship.

A demo walks through authoring an Activity Plan from a use-case description, with agents drafting the routine pieces and your team editing in. We'll run it against real documents in the same session.