Who gets to change a process when an AI agent does the work?

Build agents that prepare work. At Slate, marketing lead Andrew Harding set the search criteria and built an agent in Zapier Agents. It finds companies and contacts on the web, structures the results and writes rows to Google Sheets. Harding reports more than 2,000 leads in one month. That measures volume, not quality: to assess quality, we would want to know how many contacts matched the criteria and how many turned into conversations. The case presents sending leads on to Salesforce as an option. Zapier on Slate

At Motive, the HR team built an agent to help employees prepare their self-reviews. The agent uses past reviews, project documents and other work records available in Glean. It suggests areas to reflect on and questions about the employee’s work. Glean reports 1,100 runs in the first self-review cycle. The case does not define a run or report the number of unique users. In another Glean case, Storable’s implementation team built an agent to prepare for its first call with a customer using Salesforce, Gong transcripts and email. Glean on Motive · Glean on Storable

Let an agent update operational data. Rush Home founder Marcus Rush built Russ using Claude, Zapier MCP and Follow Up Boss. He set up a custom API layer for the CRM. After a new interaction, Russ recalculates the lead score, writes it back to the contact record, and prepares the team’s morning list of priorities. We know who built the agent, which tools he used and which field it updates. Rush Home is a small brokerage. Access to a CRM in a large company may involve a different set of people. Zapier on Rush Home

Storable also has an agent that writes to Salesforce. Glean’s account mentions custom actions and role-based access. It identifies the people who built the first-call agent, while leaving it open who configured the Salesforce write actions. The two cases establish different things even within Storable. Glean on Storable

Change the rules of an agent already in use. Perplexity’s support team works with Sage on Decagon. When the agent mishandles a request, the team can adjust its instructions, tone or escalation rules and test the change itself. Each revision no longer needs an engineering ticket. Decagon still helps the team with edge cases and learning the platform. Its account leaves open who authorizes production releases. Decagon on Perplexity

Larger deployments show how companies offer different kinds of access. Microsoft describes hundreds of employee-built or shared team agents at agricultural equipment maker AGCO, alongside larger enterprise solutions AGCO co-builds with Microsoft. AGCO trains employees and supports a Copilot Studio maker community. GE Appliances reports more than 800 agents deployed across manufacturing, logistics and supply chain. It separately names the Gemini Enterprise app for employee-built agents and the Gemini Enterprise Agent Platform for development and operation. The announcement leaves open how many of those agents employees built themselves. Microsoft on AGCO · GE Appliances on Gemini Enterprise

I would distinguish three rights in self-service. One determines who can change the agent. Another determines who can use the new version. The third governs what the agent can do in the company’s systems. Different people can hold each of these rights.

Products already make some of these distinctions. In Glean, permission to edit an agent does not by itself let you publish it. The administrator determines the largest audience an ordinary member can share with. A tool in Copilot Studio can run using the user’s credentials or a configured connection. That choice affects which records two employees can see and whose identity the destination system can record. The question matters for scheduled jobs because a user may be absent when they run. Glean permissions · Copilot Studio tool authentication

Suppose a quality team can already look up batch records and release new agent versions for its shift. It now wants the agent to open a nonconformance record. If the platform provides a “create draft” action, the team can add it and test it. If there’s only a generic write API, someone first needs to expose a narrower action. It can require a batch ID, allow only draft status and guard against duplicate requests. Once that action exists, the next team can reuse it without a new integration project.

BCG proposes redesigning the work end to end. In one published example, an industrial company reconsidered how it handled requests for quotes, from incoming email to order. It planned to give agents the straightforward cases involving products with established specifications. People still handle complex requests. The design changes the route a request takes and the point at which a specialist gets involved. BCG does not name the company, and presents the split between cases as a design. BCG on redesigning processes

There are cases from quality management, too. GE Appliances uses Gemini Enterprise to find visual patterns in customer feedback faster. It describes AI analysis for picking up defects earlier. Its announcement leaves open how that system connects to decisions on individual batches. GE Appliances on Quality Insights

Consider a hypothetical factory. An operator spots a cracked part on the assembly line and records a photo and product number. A quality engineer looks up the batch, checks recent operations and similar defects, and asks the shift for details. Then the engineer decides whether to restrict use of the batch. Some of the delay comes from waiting for the right person to gather evidence from three systems.

Give the agent a defined outcome. Get the report to a state where the engineer can make a decision. One engineer might start with the photo, another with the batch history. The agent can also choose the order. If the product number is clear, it can look up the production history. If the number and image do not match, it can ask the operator. If it finds a similar defect, it attaches a source and explains the similarity. The result is a draft record with a batch, links to evidence and open questions. If the batch cannot be confirmed, the engineer gets the case with the evidence gathered so far.

Test the change to the process as well as the quality of the answers. Here the agent takes a report from a shared queue and owns information gathering until the record is ready or an engineer takes over. A person no longer has to request each lookup in turn. In the pilot, I’d also count human handoffs, repeated data entry and waiting time. This is the first part of the redesign. To assess the whole flow, also measure time to the batch decision and returns for missing information: faster preparation can simply grow the engineer’s queue.

Ordinary software logic is useful here. Authorization, deduplication and recording the decision should work the same way regardless of the route the agent took. The API and the quality system can enforce the checks and record the result. If the work has to wait until the next shift, the system needs to save state and pick up where it left off. The platform, a task queue or an existing workflow engine can do that. The team changes the agent’s instructions for handling images, missing information and exceptions.

If you build the execution layer in-house, LangGraph can store an agent’s state and resume after a pause. Temporal supports durable execution of application code, including recovery from failures. You still have to decide where the quality specialist will see the case, how they can release an update and who grants write access. Whether you need a separate BPMN engine is easier to decide once you know where the record lives, who is waiting on whom and what has to survive a restart. LangGraph persistence · Temporal documentation

In Measuring Agents in Production, 16 of 20 in-depth cases used structured workflows and 17 used custom implementations with direct API calls. In the separate survey, 61% reported using frameworks. Of 60 responses about autonomy, 41 reported ten steps or fewer before human intervention. Data came from April–November 2025; the paper appeared in 2026. This participant sample does not represent the whole market. It shows bounded workflows, frameworks and custom implementations coexisting. Pan et al., study limitations and sections 5.4–5.5

Start with the action when comparing platforms. “Create a draft nonconformance record” needs an authoritative source for batch and quality records, a way to invoke a validated action, and an environment that decides when to invoke it, preserves state and lets the team change rules. If a vendor shows you a builder, ask them to run a case through to the write in the target system and show who can stop the next run.

Sources for the comparison. Glean on Motive · GE Appliances · Microsoft on AGCO · Maestro Agent Studio and Castrol · Palantir architecture and Eaton · Frontier Alliance and OpenAI Deployment Company · PwC Outcomes Hub · Mercado Libre

Genpact offers a ready-made accounts payable process. Wesco’s CFO reported that on Genpact AP Suite, 40% of its more than 3 million annual invoices were handled without human intervention. The case covers data extraction, duplicate detection and exceptions. It leaves open who can change invoice processing rules at Wesco. Genpact describes its current Onyx platform in a separate source. Genpact on Wesco · Genpact on Onyx

A company can also hire engineers to add an operation to its own product. Tribe AI and Galley shipped an importer that turns recipe files into structured Galley data using Claude Sonnet through Amazon Bedrock. The importer runs in Galley’s production product with human review, and Galley’s internal teams use the bulk import for migrations. The case leaves open who can edit its behavior after release. In another industry, Ode with Anthropic and PointClickCare announced that they were embedding models in PointClickCare’s platform for administrative work. The August announcement describes development. If you hire an implementation team, establish who gets access to the rules, tests and logs after launch. Tribe AI on Galley · Ode on its work with PointClickCare

A company can combine these offers. A large factory might need outside engineers to link quality records to planning, and a builder that lets quality engineers add a known defect pattern themselves. In a demo, I’d ask the future process owner to run a case and then make one change. Check whether another team has to step in to revise a rule, release it to another audience, or add a new action.

Come back to the factory three months later. It has a new line, a part has changed supplier, and the defect log contains photos that look alike but have different causes. Who notices that the agent keeps linking these photos to last year’s case? Who adds the examples to the tests and releases a new version? That tells you who actually owns the process.

I would assign three responsibilities for this process. The job titles depend on the company; in a small team one person may cover several responsibilities. The following is a proposed design for our example.

The process owner knows when the work is done. Here it is the area’s quality lead. The team labels real examples, decides what counts as a wrong escalation and chooses which rules to change. It can release updates to query order or escalation criteria within the permissions it has for that area.

The system owner decides which operations are available in the first place. In the factory these might include creating a draft, changing its state or restricting use of a batch. An authorized action validates parameters on every call. Extending access to another plant, granting writes to a new field or expanding the set of allowed actions goes through a permissions change on the system side.

The platform team makes it possible to reuse what has been integrated. It maintains the catalogue of approved actions, versioning, the test environment and an audit trail. The trail shows who or what triggered the agent, which version ran, which tools it used and what was written. During an incident, the process owner needs a way to turn off automatic runs. The platform team needs a way to revoke access to the affected action.

Companies formalize this work in different ways. In October 2026, BBVA introduced The Frame, a common standard for building, deploying and governing agents. The announcement describes the standard’s introduction; it does not establish how widely business units can already release changes independently. BBVA on The Frame

Microsoft Digital publishes a more concrete boundary. Internally, knowledge agents in SharePoint and Microsoft 365 Copilot need no proactive IT review. Copilot Studio agents with read-only actions in a personal developer environment can be shared by link with up to ten people. Broad publishing requires review; custom agents for the corporate catalogue undergo security, privacy, accessibility and responsible AI reviews. These are Microsoft’s internal policies, not product limits for every customer. Microsoft Digital’s policy matrix

MIT CISR describes the opposite problem. At the anonymized FinCo, a low-risk prototype without sensitive data waited six months for approval. The case draws on interviews with 17 leaders in 2025. The authors recommend preapproved categories and reassessment as risk grows. For our factory, that means agreeing which changes the quality team can release before an approval queue develops. MIT CISR on minimum viable governance

Independence also takes training. Motive connected its main sources, recruited departmental champions and rolled out access in stages. Its AI Labs gave employees expert help and a place to discuss their own work. The case describes this adoption mechanism without measuring its effect on agent quality. Glean on adoption at Motive

A routine change in practice. In Glean, the builder edits a draft while colleagues keep using the published version. If the sharing scope requires approval, the staged version and change message go to a moderator; otherwise an authorized user can publish directly. An older version can be restored as a new draft. Permissions and sharing settings are not part of version history. Glean drafts and versions

After release, builders need usage and failure information. Glean provides run statistics and feedback; access to detailed diagnostics depends on workspace settings. Restoring old rules still cannot repair records already created. In our pilot, the team must use the log to identify affected records and decide which need correction. Testing a version, monitoring it and repairing its effects need to be within the process team’s reach. Glean builder insights

To see whether IT has less work to do, I’d measure how many routine changes the team released on its own and how much time passed between finding an error and releasing a fix. Measure the wait for a new action separately. If a team can change a rule in a day but waits a quarter to write a new kind of record, access and integrations are the bottleneck.

Pick one outcome. On one line and for one family of parts, take a report as far as a validated draft nonconformance record. Establish a baseline from the previous weeks’ records. Measure the elapsed time to draft, active engineer time and the share of cases where someone corrected the batch or the defect type. Agree on the most serious exceptions and include them in a separate part of the test set.

Replay past cases and run in shadow mode. Use only information available when the report arrived, keeping the engineer’s eventual diagnosis out of the input. Reserve some cases for final evaluation and do not use them for tuning. Then run read-only on fresh reports. Check batches, evidence, missed escalations and errors on unfamiliar defects. Repeat trials: one successful attempt does not establish reliability. Anthropic distinguishes the model’s answer, its trace and the state of the system. Here that means checking the record actually created in a test environment. Anthropic on agent evaluations

Authorize one kind of write. Before launch, the quality owner and platform team agree which fields and evidence make a record usable, which errors are unacceptable and what benefit justifies operation. Once the evidence meets those criteria, give the agent the “create draft” action for that line. The engineer sees the data and links before accepting the record. Difficult cases can still follow the familiar manual route. Exercise duplicate event delivery, stale batch data and an unavailable source. The team can then see when the agent retries safely, when it waits and where it sends the case.

Compare against manual handling. Keep a contemporaneous manual stream for comparable reports. Where feasible, assign cases randomly within groups of similar complexity before processing, and track unfamiliar defect types separately. For rare critical defects, zero observed errors in a small sample does not establish safety. With insufficient evidence, do not expand permissions. Pilot duration depends on usable observations and case coverage as well as calendar time.

Calculate the cost per accepted record. In a hypothetical month, engineers spend 12 active minutes on each of 100 reports they handle manually, or 20 hours. At the same volume, the pilot produces 80 drafts that engineers accept after four minutes of review each. Engineers complete the other 20 themselves at 14 minutes per record, including time spent inspecting the draft. The team spends another two hours operating the workflow. That comes to 12 hours of human work: 7.2 minutes per accepted record instead of 12, or eight hours saved per 100 records. In a real pilot I’d add the platform and inference charges and time spent on later corrections, and show one-off integration costs separately. Check that the two groups have a comparable mix of defects. The cost per accepted task

With labor at an illustrative ₽3,000 per hour, manual handling costs ₽60,000 a month, while human labor with the agent costs ₽36,000. At the same quality and volume, that leaves up to ₽24,000 a month for the platform, model calls and other recurring costs. That figure is the ceiling in this example. If headcount and pay stay the same, the realized benefit depends on what else the team gets done in those hours.

The average can hide the biggest risk. Ten drafts finished quickly count for little if a serious defect quietly lands in the routine queue. Before launch, I’d define a concrete event that stops automatic writes. For this pilot, stop at the first confirmed critical defect that the agent left in the routine queue. Revert that stream to manual processing, reproduce the case and run the fix against similar examples. Until the cause is fixed and the acceptance criteria are checked again, the agent runs read-only and the engineer creates the records. Keep that arrangement if the evidence remains insufficient.

In the final week, I’d try something a sales demo rarely covers. Ask the quality team to make one change on its own, such as adding a new signal for fast escalation. The team should be able to test it on past cases, release it on its line, see what changed in the real records and roll back if needed. One cycle tells you how much work the agent picked up and whether the people closest to that work can now change their own process.