Activities: A Noun the Business Can Use

Why we made Activities a first-class concept in the 2026.4 release, and what it changes for the operations leaders who run document-heavy work.

Most operations leaders cannot tell you what their document AI is doing right now. Not because they do not understand the work. Because nobody has given them a noun for it.

When you ask, the answers come back in IT language. It runs the pipeline. It executes the jobs. The bot is processing the queue. None of those describe a thing the operations leader owns. They describe a thing IT owns, on the operations leader’s behalf. The gap between those two streams — the work the platform does, and the work the business can talk about — is where document AI deployments tend to feel disconnected from the people who run the process.

In our 2026.4 release, we made Activities a first-class concept on the platform. This post is about why that small linguistic change matters more than it sounds.

What an Activity is

An Activity is one run of automated work. A specific instance, with a specific set of inputs, a current status, a sequence of Steps the platform has executed or is executing, and a set of results. It is something you can count, monitor, retry, and audit.

We made the symmetric move on the human side. The work your people do, reviewing, approving, handling exceptions, is now structured as Tasks. Same first-class treatment: owned, reviewable, and completable, with the document and the system context attached. An Activity creates a Task when it needs a human. The Task completes, the next Activity fires. Every transition, automated or human, sits in one audit trail with the same shape.

That is the model. Two nouns the business can hold, joined by a workflow that the audit team can read end to end.

Why this bridges closer to the business

There are five practical things this changes in the conversations we have with operations leaders.

1. The business gets a noun it owns

Before this release, the platform’s automated work was described mostly in pipeline terms — useful for engineers, opaque to operations leaders. Activities give the business a noun.

We ran 12,400 Activities yesterday. 11,800 closed without human review. 600 created Tasks; 580 were resolved within SLA. That is a sentence a Head of Operations can put on a slide. It is not a sentence anyone could write about a pipeline.

2. The audit trail is automatic

When automated work and human work live in different systems, the audit trail for any single piece of work has to be composed at the end out of email exports and ticketing screenshots. With Activities and Tasks sharing the same audit shape, every transition is captured with the same controls, the same retention, and the same query language. There is one place to look when work is in motion, one place to look when it has finished, and one place to look when something went wrong.

3. Steps make the model risk conversation tractable

Inside an Activity, the work is composed of typed Steps: a script step, a service-bridge call, an LLM step, an approval step, a step that creates a Task. That separation matters when the model risk team comes asking which parts of this is the foundation model doing, and which parts are our rules doing. The Step graph answers that question by construction. Compliance can audit the LLM Steps separately from the deterministic ones, and there is no ambiguity about which is which.

4. The pattern, not just the run, is reusable

The definition of how an Activity runs, its inputs, its Step graph, its dependencies, is an Activity Plan. Activity Plans live at the organisation level, bound to projects rather than copied into them.

The commercial implication is the one operations leaders care about. The first deployment pays for the patterns. The second business unit to need a similar workflow binds the existing Activity Plan rather than rebuilding it. Lending Operations builds the loan-packet workflow; six months later, Specialty Finance adopts it as a configuration job, not as a project.

5. Triggers let the business describe the choreography

Triggers are the wiring that says when X happens, start Activity Y. When a Task moves to Approved, post to the GL. When a covenant exception is overridden, run the downstream notification. When a new vendor packet arrives, classify and route.

That is a description an operations leader can write themselves. It maps onto how they describe their process in a meeting room. The platform does not need to be configured by translating their language into something else.

What this is not

Activities are not a magic noun. Operations leaders have always been able to count things. What changes is that the thing they count, monitor, and audit is now the same thing the platform runs, not a derived metric pieced together from logs, tickets, and exports.

The deeper change is that the platform now talks about its own work in the same language the business uses. Activity. Task. Activity Plan. Trigger. Step. Eight terms that fit on one piece of paper, that an operations leader and a platform engineer can use without translation.

That alignment, small as it sounds, is what closes the distance between the platform and the business. Document-heavy operations are run by both. They should be able to describe the work the same way.

---

The 2026.4 release notes are on the changelog page. The full vocabulary, with definitions, is in the developer concepts guide.