Copilot Studio: agent accounts, business process memory and triggers

Microsoft Copilot Blog · 15 October 2026

Microsoft has started rolling out three Copilot Studio capabilities through its Frontier programme. With agent accounts, an agent works under its own credentials and scoped permissions instead of borrowing a user’s or maker’s identity; people can call it in Teams and Outlook and @mention it in Word, Excel and PowerPoint comments. Business process memory carries preferences and process context into the next cycle; makers switch it on, and users can view and delete what was saved. Triggers start an agent’s cycle from an external signal such as an e-mail, or on a set cadence, without a prompt. Admins can scope access and manage the agent’s lifecycle in the Power Platform admin center. Further access policies, cost management and lifecycle controls are planned “in the coming months”. The post gives no general-availability date, licensing or price.

Why it matters. The robot-account question RPA teams have argued about for years has moved inside the office suite. An agent with its own identity is the right call for the audit trail, because it separates what the agent did from what a person did. My reading: an agent with a mailbox and a Teams presence sits squarely within the KVKK principle decision from last issue, and memory brings its own questions about retention and privacy notices. I wouldn’t multiply these accounts in production before the cost and lifecycle controls land. For a pilot, start simple: one owner, one purpose and a list of the channels each account may read.

The first harmonised standard under the EU AI Act: EN 18286

European Commission · decision of 12 October, Official Journal 14 October 2026

Commission Implementing Decision (EU) 2026/2274 published the reference of EN 18286:2026, a quality management system standard for AI drafted by CEN and CENELEC, in the Official Journal. According to the Commission, providers of high-risk AI systems that apply it get a presumption of conformity with the Article 17 quality management requirements it covers. The standard is built around the AI system’s lifecycle rather than the organisation, and is designed to sit on top of ISO/IEC 42001, ISO 9001 or sector systems. Organisations without 42001 can use it to extend an existing QMS or build a new one. The Commission says more harmonised standards will follow.

Why it matters. Until now, high-risk obligations came with legal text and draft guidance, but no concrete answer to an auditor’s “measured against what?”. EN 18286 is the first one. If your company sells AI-enabled products or services into Europe, bring the quality team that runs your ISO 9001 or 27001 into the conversation now. One caveat: this covers Article 17 only. Whether your system is high-risk in the first place is a separate question, and it comes first.

Türkiye’s Communiqué 596: a 30 November e-notification deadline, and a rule on sharing passwords

Official Gazette of Türkiye · 11 October 2026 (Issue 33397)

Tax Procedure Law General Communiqué No. 596 resets the procedures for electronic tax notifications under Article 107/A, as amended by Law No. 7587, and repeals Communiqué No. 456. Corporate taxpayers, individuals taxed on actual business, agricultural or professional income, and general and limited partnerships must join the system. Those not yet enrolled have until the end of the month after publication, which is 30 November 2026; new taxpayers must join within 15 days of starting business. A notice counts as served at the end of the fifth day after it reaches the system, and event logs are time-stamped and kept for thirty years. Recipients must protect their user code and password, not share them with third parties and not let others use them. Anyone enrolled before 1 July 2026 carries on with existing credentials.

Why it matters. A robot that checks the e-notification inbox every morning and routes notices to the right team is one of the most common finance automations in Türkiye. The five-day rule is a reminder that a day of robot downtime is a day off a legal deadline, so monitoring and alerting here are not optional. The more delicate point is the password: write down which identity the robot uses to log in to the Digital Tax Office, and under whose authority. Ask your financial advisor and legal team how the no-sharing rule applies to robot accounts; this isn’t legal advice. And if a group company still isn’t enrolled, the last day is 30 November.

UiPath: AI audit logging default changes, Claude Sonnet 4 removed

UiPath Documentation · 13, 14 and 16 October 2026

Since 16 October, new AI Trust Layer policies no longer save prompt inputs and model outputs in audit logs by default; until saving is enabled, those fields show as “Blocked by Policy”. Existing policies keep their setting. On 13 October, following its retirement on Amazon Bedrock, Claude Sonnet 4 was removed from the UiPath platform; UiPath-managed models moved to Claude Sonnet 4.6 automatically. Bring-your-own (BYO) configurations still pointing at Sonnet 4 become invalid and fall back to UiPath-managed models unless updated. Model Hub now shows the status of BYO configurations. Separately, Relay can now carry Snowflake and SQL Server connections from on-premises networks, with Relay client 26.4.4 or later.

Why it matters. Not logging content by default is sensible for data protection, but if you ever need to investigate an agent’s bad decision, the prompt and the response may simply not be there. I think this should be a policy decision, not a default: which processes keep content logs, for how long, and who can read them. The Sonnet 4 note is the quieter risk. Where you brought your own model, an agent may have fallen back to a different one without anyone noticing, which is both a quality and a data-residency question. Check the BYO status in Model Hub this week.

Maestro: Flow leaves preview, and a coding agent can now build a BPMN process

UiPath Documentation · 7 and 13 October 2026

The 13 October notes unify the canvas names as Maestro BPMN, Maestro Case and Maestro Flow, and Maestro Flow is no longer labelled as preview. In Maestro Case, stages that can end a case get a badge, failed or terminated stages no longer show as in progress, a new API endpoint lists the ad-hoc tasks available on a case, and role definitions are validated. In Flow, your own guardrail configuration now appears by name with its provider. A preview from 7 October lets a coding agent such as Claude Code, Codex, GitHub Copilot, Cursor or Jules build a Maestro BPMN process from a process description, a process map, a PDD or a BPMN model. The agent proposes a plan for approval, then builds, debugs and deploys.

Why it matters. Handing part of the PDD-to-process path to a coding agent is tempting, but the output can’t be better than the PDD. A weak PDD now turns into a wrong process faster. I’d treat the agent’s plan like a design review and record the approval. Flow leaving preview makes a production decision easier; still check the support and release terms in your own contract.

Gartner: over $3.5 trillion of AI infrastructure spending could face impairment by 2030

Gartner · 14 October 2026

According to the title of Gartner’s 14 October release, more than $3.5 trillion of AI infrastructure spending could be exposed to impairment by the end of 2030. Gartner’s page blocks automated access, so this item rests on the title alone; other figures visible in search snippets couldn’t be read on the primary page, so I’ve left them out.

Why it matters. It reads like a warning to infrastructure investors, but enterprise buyers are exposed too. If model and GPU providers consolidate, the company or the price behind a multi-year AI contract can change. My rule: an architecture that keeps the model swappable (an abstraction layer, your own evaluation set) and a contract with an exit clause. This week’s Sonnet 4 note is a small example of how quietly a model can change underneath you.

Next week I’ll be watching whether Microsoft publishes licensing and cost controls for agent accounts, and which harmonised standards line up behind EN 18286.

KVKK: a principle decision on monitoring workplace e-mail and communication channels

Official Gazette of Türkiye · 8 October 2026 (Board decision of 16 September 2026, No. 2026/2035)

Türkiye’s Personal Data Protection Board published a 16-point principle decision on how employers may monitor corporate e-mail and other channels used for work. It isn’t limited to e-mail: internal messaging, CRM and ticketing systems, and chat and recording areas in meeting platforms are named too. Processing only traffic and log records, without opening content, still counts as processing personal data. A generic “your mailbox may be monitored” notice does not meet the duty to inform; the notice has to say concretely whether logs or content will be reviewed, when content may be accessed, and how long data is kept. Monitoring through tools that record everything an employee does, indiscriminately, is treated as unlawful. Access to the collected data should be limited to authorised staff and logged.

Why it matters. It reads like an HR policy document, but automation teams are squarely in scope. A robot reading a shared mailbox, an agent watching Teams channels, or a task-mining tool recording every click on a desktop all operate in exactly these channels. My reading: “record everything and filter later” is no longer a defensible design. This week I’d check two things: the list of mailboxes and channels your robots and agents read, and who can see the logs and recordings those tools produce. If there’s no list, the privacy notice is probably incomplete as well. This isn’t legal advice; read the text with your legal team.

UiPath Agents: review by Autopilot and bring-your-own guardrails

UiPath Documentation · 1 and 8 October 2026

Agent review, in preview since 8 October, replaces the old Agent score. Autopilot reviews an agent, lists critical issues, warnings and improvements, grades it from A to F by the number and severity of issues, and can apply the fixes in the same conversation. On 1 October, also in preview, organisations gained the option to add their own safety-vendor subscription to the AI Trust Layer and use it for agent guardrails. Supported providers during preview are Azure AI Language, Azure Content Safety and Noma. Each detection appears in the agent trace with the provider that produced it, and a guardrail can fall back to its UiPath-managed equivalent if the provider can’t be reached.

Why it matters. Using your own guardrail subscription means the content filters your security team already approved can follow you into agents, which may shorten sign-off. Watch the fallback behaviour, though: which rule applies while the provider is down will be one of the first audit questions, and that should be a written policy decision. I’d treat the A–F grade as preparation for code review rather than a quality gate. A good grade shortens the review; it doesn’t replace it.

Orchestrator: enforced tenant encryption and Maestro Flow identity

UiPath Documentation · 7 and 12 October 2026

Since 7 October, Orchestrator tenants can turn on enforced encryption: job, job event, robot log, queue item and storage bucket data are encrypted at rest with a KMS key. You enable it through your technical account manager or UiPath Support, and encrypted fields can’t be searched. The 12 October notes add a trace ID in job fault details when a robot fails to fetch credentials, and Maestro Flow node jobs without a named robot now run under the caller’s identity. Separately, the Automation Cloud notes of 6 October say allowlisting Cloudflare’s 104.16.0.0/13 range may be needed for any UiPath service, not only Document Understanding; UiPath recommends DNS-based allowlisting where possible.

Why it matters. Encryption is a concrete answer to one of the most common objections to cloud Orchestrator in banking and insurance. The cost is just as concrete: you lose search on encrypted fields. If operations staff look up queue items by reference, talk about that habit before switching it on. The Maestro Flow identity change looks small but alters the permission model, because the audit trail will now show a different identity doing the work. And if your network restricts outbound traffic, the Cloudflare note may be the most practical item this week.

Google Cloud: the Gemini agent, “one agent for work”

Google Cloud Blog · 8 October 2026

At Gemini at Work 2026, Google Cloud introduced a single agent that answers questions, does knowledge work, creates images and writes and runs code. It runs persistently in the cloud, carries on with long jobs after the user closes the laptop, and can orchestrate both Gemini and Anthropic’s Claude models. Each agent gets a cryptographically attested identity with least-privilege permissions; actions land in an audit trail attributed to the agent rather than a person, traffic passes through Agent Gateway, and spend caps can be set per project. It can connect to MCP servers inside or outside the company network. Financial services and legal editions are in preview; the post gives no availability date, edition or price for the agent overall.

Why it matters. An “agent coworker” with its own identity, mailbox and spending cap is the latest version of the RPA robot-account debate. The identity and audit design points the right way. My question is different: when one process involves a UiPath robot, a Copilot flow and a Gemini agent, who keeps the end-to-end trace? I wouldn’t open a budget line before availability dates and data-residency details arrive. MCP support I’d count as good news; publishing your tools once as MCP servers lowers the cost of switching platforms later.

Automation Anywhere to acquire Boost.ai

Automation Anywhere · 7 October 2026

Automation Anywhere announced a definitive agreement to acquire Boost.ai, a Norwegian conversational and voice AI company, from Nordic Capital. Closing is expected in the fourth quarter of 2026, subject to customary regulatory approvals; terms were not disclosed. According to the release, the Boost.ai platform supports more than 36 languages and is strongest in regulated sectors such as financial services, telecoms and insurance. The company frames the deal as connecting the customer conversation to the back-office work behind it.

Why it matters. Platform vendors are moving to sell the front end (chat, voice) and the back office (robots, agents) as one package. If you run Automation Anywhere and hold a separate chatbot contract, the renewal conversation will change. The release doesn’t list the supported languages; I wouldn’t plan a consolidation before asking how well Turkish works in production and where the data is processed. One vendor makes integration easier and makes leaving more expensive.

Gartner: procurement leaders are stalling on AI role redesign

Gartner · 8 October 2026

According to the title of Gartner’s 8 October survey release, chief procurement officers are stalling on the role and job redesign that AI requires. Gartner’s page blocks automated access, so this item rests on the release title alone; I couldn’t verify the survey figures on the primary page, so I’ve left them out.

Why it matters. Procure-to-pay is one of the most mature areas for automation. As robots and agents take on the work, the remaining human roles rarely get redefined, and exception queues end up with no owner. If your business case books capacity gains, write on the same page which new role or work that capacity goes to. If you can’t, the gain stays on paper.

Next week I’ll be watching how organisations and law firms update their privacy notices after the KVKK decision, and whether UiPath gives a general-availability date for the guardrail and agent review previews.

Why now

General Communiqué No. 589 on the Tax Procedure Law, published in the Official Gazette on 31 December 2025, gave one more year to a specific group of taxpayers outside the e-Fatura and e-Arşiv systems: those on the simplified method or keeping business-account books. According to TÜRMOB’s circular, until 31 December 2026 they may still issue paper invoices up to 3,000 TL including taxes. From 1 January 2027 they must issue every invoice, whatever the amount, through the Revenue Administration’s e-Belge portal. For all other taxpayers the same rule has applied since 1 January 2026.

Seen from the buyer’s side, the meaning is simple. For a company that buys from tradespeople and small suppliers, the paper channel into accounts payable largely closes in 2027. Almost every incoming invoice will be either e-Fatura or e-Arşiv. I noted this briefly in the first radar. The question here is more practical: is the robot you already run ready for it?

What we delivered

The e-invoice robot we built connects an ERP platform end to end with the national e-invoice infrastructure and produces a reconciliation report. We have built these integrations with Logo Tiger 3 and other ERP systems. I am not sharing the client’s name, volumes or internal detail. Some of the design notes below come from the backbone of that delivery and some from what I would add if I built a similar flow today; the labels in the walkthrough separate the two.

The Revenue Administration states the basic rule plainly: two taxpayers registered in e-Fatura must send and receive the invoices they issue to each other as e-Fatura. An invoice to a buyer who is not registered is issued on paper or as e-Arşiv. So a company’s incoming invoice flow is not one format; it is fed by at least two. The robot’s first job is to tag that difference at the source.

Why reconciliation is a separate job

Integration says “record the incoming document”. Reconciliation says “show that what you recorded is complete and unique”. The two can live in the same code, but they answer different questions and different people read them.

In a reconciliation report I want to see three lists:

• Invoices visible on the e-invoice side with no counterpart in the ERP. These are usually pending, rejected, or skipped by the robot because of an error.
• Invoices recorded in the ERP that cannot be tied to an electronic document. Manual postings and leftovers from the paper channel show up here.
• Invoices on both sides whose amount or tax doesn’t agree.

If the first two lists are empty, the robot is doing its job. If they’re not, you want to know the next morning, not at month-end close. I think that is the real value of the report: it moves errors out of closing week and into daily work.

Where the rule, the model and the person sit

Rules carry most of this flow, and they should. An electronic invoice already has structured data. I see no reason to have a language model read the amount, the tax or the supplier. Duplicate checks, matching against order and goods receipt, and tolerance rules should be deterministic and explainable to an auditor in one sentence.

A model comes in for documents without structured data. Until 2027 that means paper invoices from small suppliers. I don’t expect it to disappear entirely afterwards. How an electronic document reaches you can depend on the supplier’s choices, and some invoices will still arrive only as a PDF. So I would keep the reading path, but build it as part of the exception path rather than the main flow.

The person is the only party who knows why a difference exists. Does a price gap come from an agreement, a partial delivery or a wrong order? I don’t want the robot to invent an answer; I want it to take the question to the right person with the right information.

Four things to adjust for 2027

1. Redo the volume forecast. If you run an OCR flow for paper invoices, 2027 volume will very likely fall. Don’t renew licences and capacity on this year’s figures; split your supplier list by who is on the simplified method or business-account books and forecast from there.
2. Make the channel tag mandatory. Keep the source channel on every invoice record. Without it you cannot measure whether the paper channel has actually closed.
3. Consider a separate intake path for e-Arşiv. The form in which an e-Arşiv invoice reaches you can vary by supplier. Before January, collect samples from your small suppliers and look at what actually arrives; don’t design on assumptions.
4. Break the reconciliation report down by channel. Seeing which channel the unmatched invoices came from often shows at a glance whether the problem sits in the robot or with the supplier.

When a robot is the wrong choice

To be honest, this job doesn’t always need a robot. If your ERP’s own e-invoice module or your private integrator’s standard connector covers the need, use that first. The Revenue Administration itself lists the portal, integration and private integration as separate ways to use e-Fatura. A robot earns its keep in the gap that connection leaves open: several ERPs, matching rules specific to your process, or a reconciliation task nobody owns.

Then there is maintenance. A robot that works through the screen needs checking with every ERP version change. Wherever possible I’d use a service or database interface instead of the screen, and keep the screen for steps that have no other way in.

Before you copy it

If you are thinking about a similar flow, ask one question on Monday: how many days does it take us to notice that an invoice visible on the e-invoice side is missing from the ERP? If the answer is “at month-end close”, your priority is reconciliation, not integration. And the 2027 calendar is not a good reason to postpone that work. It is a good date to start it.

UiPath FUSION 2026: Maestro is now two products

UiPath · 23 September 2026

At FUSION 2026 UiPath split Maestro in two. Maestro Orchestrate is for long-running processes that cross teams and systems; Maestro Automate is for small, fast, high-volume tasks. Several things went generally available in the same announcement: Cartographer, which drafts and maintains a “Map of Work” from documents, systems and people; UiPath for Coding Agents, which lets developers build with the coding agent they already use; and Delegate, a desktop agent. Dark Testing Factory is in preview and the Map of Work itself is on the roadmap.

Why it matters. The split turns a decision teams already make into a product boundary. A case that stays open for weeks waiting on human approval and a queue item that finishes in seconds shouldn’t be governed by the same rules. Make that distinction in your architecture documents now: which processes hold state, and which only carry volume? I’d treat Cartographer as a way to keep the PDD current, not as a replacement for writing one. My first test would be a small process that already has documentation, comparing the output against what’s on file.

Gartner: most vendor-built agents will be abandoned

Gartner · 29 September 2026

Gartner’s 29 September release predicts that 70% of enterprises will abandon agentic AI built by a vendor’s forward-deployed engineers by 2028. The published summary points to rising costs and to organisations being unable to evolve these systems on their own. Gartner’s page blocks automated access, so this item rests on the release title and its published summary.

Why it matters. Outsourcing an agent build isn’t the problem. Being unable to maintain what you received is. I would put three things in the contract: versioned prompts and tool definitions, the evaluation sets used in acceptance testing, and at least one change made by the internal team alone after go-live. If the third can’t happen, what you have is a dependency, not a product.

Model Context Protocol 2026-07-28: the protocol is now stateless

Model Context Protocol Blog · 28 July 2026

The 28 July release moves MCP’s core to a stateless request-response model. The initialisation handshake and session IDs are gone; each request carries its own version and capability information. When a server needs input mid-call it now uses Multi Round-Trip Requests, and method and tool names travel in HTTP headers (Mcp-Method, Mcp-Name). Authorisation was tightened, and Tasks, MCP Apps and Enterprise Managed Authorization became official extensions. Roots, Sampling and Logging are deprecated, with at least twelve months to migrate.

Why it matters. If you run MCP servers in-house there is good news on two fronts. Servers scale horizontally without sticky sessions, and a gateway can see which tool is being called and apply policy without opening the request body. That gives you something concrete to discuss with the security team. The work is clear too: list which of your servers use the deprecated features now. Twelve months is short if you don’t have an inventory.

EU AI Act: high-risk delayed, transparency not

Official Journal of the European Union · 24 July 2026

Regulation (EU) 2026/1744, the Digital Omnibus on AI, entered into force on 27 July, three days after publication. Obligations for high-risk systems under Annex III move to 2 December 2027, and those for systems embedded in products under Annex I to 2 August 2028. The Article 50 transparency duties did not move; telling people they are dealing with an AI system has applied since 2 August 2026. Providers whose generative systems were on the market before that date get a four-month transition for machine-readable marking of outputs, which ends on 2 December 2026.

Why it matters. For Turkish companies serving the EU, or with EU customers, the order of work has changed. There’s breathing room on high-risk classification, but if a chatbot talks to customers or a flow generates text for them, the disclosure duty is current. I’d start with an inventory: in which flows is a person corresponding with a model without knowing it?

Türkiye e-Arşiv: the last quarter for small taxpayers

TÜRMOB · 2 January 2026 (Official Gazette, 31 December 2025)

General Communiqué No. 589 on the Tax Procedure Law gave taxpayers on the simplified method or business-account basis, who are outside e-Fatura and e-Arşiv, one extra year. Until 31 December 2026 they may issue invoices up to 3,000 TL including taxes on paper; anything above must be issued as e-Arşiv through the GİB portal. From 1 January 2027 every invoice they issue, whatever the amount, must be e-Arşiv. For other taxpayers the same rule has applied since 1 January 2026.

Why it matters. Companies that buy from many small suppliers still see paper or scanned invoices in accounts payable. Expect that channel to shrink in 2027. If you run an OCR flow for paper invoices, redo next year’s volume forecast with this change in mind. I’d move the freed capacity to integrations that take e-document data straight into the ERP.

IXP: priced per operation, not per page

UiPath Documentation · 8 July and 14 September 2026

Since 8 July, UiPath meters IXP extraction from unstructured and complex documents per operation rather than at a flat rate per page, and IXP and Document Understanding licences can be used together without extra per-page cost. On 23 July an option to deploy a model version straight to an Orchestrator folder entered preview. On 14 September Bring Your Own Subscription opened in preview: IXP can run on an organisation’s own Gemini or GPT subscription, eligible projects get discounted consumption, and AI Trust Layer policies still apply.

Why it matters. Document-processing business cases are usually built on page counts. Change the unit and the maths changes, and only your own sample will show which document types it helps and which it hurts. Re-run the business case on a real month of documents. For organisations that already hold a model subscription, BYOS adds an option in conversations about data residency and price. It’s still a preview, though.

Over the coming weeks I’ll be watching two things: availability dates for Maestro Orchestrate and Automate, and what model providers publish as the 2 December marking date approaches.

The logistics anomaly flow we built with UiPath Maestro and agents splits the work three ways: rule-based RPA checks, classification with a language model, and automatic exception notification to operations stakeholders. This piece is about the reasoning behind that split.

Don’t ask the model what a rule already knows

If a mandatory field on a shipment record is empty, you don’t need a language model to say so. Same if a defined threshold is exceeded or the same record arrives twice. These checks are cheap, give the same answer every time, and are easy to explain in an audit.

The model belongs where a rule can’t decide on its own. Free text is the clearest case, I think. The reason for a delay buried in an operations note, a phrase in a description field, what an inconsistency between two fields actually means: these are hard to capture with rules, and every new situation adds another rule. That’s where classification earns its place.

The ordering has a side benefit. The model only sees records the rules flagged, so cost grows with the number of suspicious records rather than the total.

Ask the model for a form, not an essay

Binding the model’s output to a predefined schema is what keeps the rest of the flow solid. The anomaly type should come from a fixed list, the rationale should be short, and there should be a field where the model can say it isn’t sure. A model that returns free text forces every later step to guess.

Writing the list of types with the operations team is part of the job. When something new shows up that isn’t on the list, a model that marks it as “other” is better than one that forces it into the wrong bucket.

Notification is design work too

Automatic notification can be the least discussed and most complained-about part of a flow. If everyone gets everything, soon nobody reads anything. When I design notifications I look at three things:

• Who receives it? The team or person responsible for that anomaly type.
• What do they see? The record, the anomaly type and a one-line rationale. Nobody should have to log in and search.
• When do they hear about it again? Not for the same anomaly, unless its status changes.

Where Maestro fits

Orchestration here means running the steps in the right order and making visible which stage a record is waiting in. Rule, model and human steps move at very different speeds: a rule finishes in milliseconds, a human review can take hours. UiPath splitting Maestro at FUSION 2026 into Orchestrate for long-running processes and Automate for short high-volume work recognises that difference at the product level. I went into it a little more in the first radar.

Put the human gate in from the start

The core of the flow we delivered is rules, classification and notification. If I built a similar flow again, I’d add a human review step for cases where the model isn’t sure from day one. My reason is simple: those records are the most valuable data you’ll get on which anomaly types trip the model up. When the human decision is recorded with a reason, the next improvement knows where to start.

Measure before you scale

Before rolling an anomaly flow out to a new region or a new data source, I’d measure three things:

1. Classification accuracy on a small labelled sample. Write it into acceptance testing.
2. The false-alarm rate. The operations team’s trust is won or lost in the first few weeks.
3. Cost per record. Model calls grow with volume; rule checks don’t.

If none of the three is measured, you have a promising demo. That’s all.

The document-processing programme we built for the Finance and Accounting function of a national flag carrier is built on that second question. It runs in the airline’s own data centre, processes supplier invoices end to end, and is live. Without going into the airline’s internal details, this piece walks through the decisions that shaped the design.

The first constraint: documents don’t leave the building

The first decision that shaped the architecture wasn’t technical. It was institutional: documents would not be sent outside the organisation. That’s a common requirement for finance documents and, I think, a fair one. A supplier invoice carries bank details, contract prices and payment terms.

The consequence is that much of what you switch on with a few settings in the cloud becomes infrastructure work on-premises. Digitisation and extraction components have to run inside. Model versions, updates and capacity planning become part of the project. UiPath’s own documentation states that Document Understanding remains available for Automation Suite and Standalone deployments, which narrows the choice of product for any organisation with an on-premises requirement.

The lesson here, as I see it, is simple: plan the on-premises installation as its own work item, not a deployment detail. If it isn’t in the schedule from day one, it will squeeze something later.

Three gaps between reading and understanding

The scope of this programme fits in three phrases: multi-currency, multi-language, multi-table. Each is its own problem.

Multiple currencies. The currency isn’t always printed next to the amount. Decimal separators change from country to country, and the same supplier can change format over time. After extraction every amount has to be normalised and its currency checked against what the supplier usually invoices in. I’d leave that check to a rule, not the model. The model can be wrong; the fact that a supplier always bills in euros is already sitting in master data.

Multiple languages. The same field arrives under different labels in different languages, and non-Latin scripts are a challenge of their own. On another project we built a separate extraction pipeline for documents in Chinese characters, and it raised accuracy by 55%. That result points at something: instead of forcing every language through one model, splitting the troublesome language into its own pipeline is worth trying.

Multiple tables. Line items can be spread across several tables, tables break at the end of a page, and subtotals can look like lines. The best insurance is, again, a rule: if the lines don’t add up to the invoice total, the document doesn’t pass automatically.

Human validation is the design, not the fallback

Two parts of this programme set it apart: the design of the validation screen, and structured human-in-the-loop escalation. The second sounds abstract, so let me unpack it.

In unstructured escalation, a document goes to a person with a note that says “please check”. They reread it, find the problem themselves and repeat the same work every time. In structured escalation the document arrives with the reason it stopped: which field, which rule, which confidence score. Documents that stop for different reasons can go to different people. An unreadable field is work for the validation team; a supplier missing from master data is work for procurement.

There are two benefits. The reviewer’s time goes to the suspicious field, not the whole document. And because corrections are recorded with their reasons, you can measure which document types and which fields cause trouble. Those records decide where model improvement starts.

I set confidence thresholds per field, not per document. A small misread in the supplier name gets caught by master-data matching; a misread amount can turn into a payment before anyone notices. Applying the same threshold to both makes little sense.

Before you copy this

If a team were starting a similar programme, this is the list I’d hand them:

1. Collect a real month of documents. Don’t estimate anything before you’ve seen the spread of suppliers, languages, currencies and page counts.
2. Write down who will work the validation screen and how much time they have each week. A human step without capacity becomes a queue that slows everything down.
3. Decide with the business which field passes at which threshold, and name the owner of that decision.
4. Define the final consistency checks before posting to the ERP as rules. However good the model is, don’t leave those to it.
5. If you’re on-premises, put hardware, OCR engine licensing and the model-update procedure in the plan as separate lines.
6. Have a rollback plan for model version changes. A new version can improve one field and get worse on another.

None of these items is about AI. Most of the decisions that decide a document-processing project aren’t.

At BOTTEQ we build document-processing lines by combining Document Understanding with Base64.ai’s OCR/ICR engines. The table below doesn’t come from that work, though. It comes from UiPath’s own documentation, with the sources at the end. The commentary is mine.

The two routes in brief

Document Understanding (DU) is for structured and semi-structured documents: forms, purchase orders, applications, invoices. It works with pre-trained machine-learning models on documents whose layout is the same or very close. Its generative features can be governed through the organisation’s AI Trust Layer policies. DU continues as a standalone service and remains available on Automation Suite and Standalone deployments.

IXP is the umbrella under which UiPath brought DU and Communications Mining together and added a new prompt-driven capability: generative extraction for unstructured and complex documents. UiPath describes it for annual reports, contracts and lease agreements. Complex tables, charts, checkboxes, signatures and handwriting, values that have to be inferred from context or stitched together across sections: that’s this route’s territory. Generative AI is mandatory here.

Decision table

Three questions the table can’t answer

Mixed bundles. When ID, proof of address and bank statements arrive in a single file, as with a loan application, the real work starts before extraction: splitting the documents and identifying their types. Whichever route you pick, settle where and how that splitting happens during the pilot. The division of labour between rules, a model and a person here can matter more than the extraction itself.

Project type. DU has a choice inside it too. Modern projects give faster, guided model development. Classic projects allow exporting models and datasets and cross-tenant use, but run only on Automation Cloud. AI Center-based projects give the most control and also support Standalone deployments, but have no Cloud API support. If you must run on-premises, that alone can decide the matter.

The cost unit. Since July 2026, IXP extraction from unstructured and complex documents is metered per operation rather than at a flat rate per page, and IXP and DU licences can be used together without extra per-page cost. If you have an old business case built on page counts, re-run it on a real sample of documents.

Two traps when moving to IXP

The label you confirm is what counts as right. IXP scores a model against the labels you confirmed. Confirm a wrong value while labelling and it becomes the reference, and the score goes up. A high score doesn’t prove the values are correct. Treat labelling as part of acceptance testing, not a chore to finish quickly.

Don’t mistake a format difference for an error. Built-in data types such as dates and monetary amounts come back normalised. If “21-JUN-22” on the page and the ISO date the model returns are the same value, that isn’t a mistake. What deserves your attention is a change in meaning, such as a misread decimal separator.

My default

If most of the document set is invoices, forms or orders with a known layout, I start with Document Understanding. I gather the documents that take the most validation time, the ones with scattered layouts or values that depend on context, into a separate queue, and I try IXP on that queue first. The two routes can run side by side in the same line. I think it’s healthier to treat the choice as a decision per document type than as a one-off platform decision.

We’ve built change-management, monitoring and incident-response frameworks inside client organisations, and at the heart of that work is a plain fact: putting a system live means giving it authority. For RPA bots that authority was narrow; a bot followed steps someone had written down. An agent picks its own next step. So the questions you ask before signing off go-live change too. Here are mine.

1. Does it decide, or recommend?

The same agent carries very different risk in the two roles. An agent that classifies a supply anomaly and puts it in front of a person is recommending. An agent that lifts a payment block on its own is deciding. Write this down for every action in the design document. “The agent does X” isn’t enough; say “the agent proposes X and this person approves” or “the agent does X and stops in this situation”.

2. Can a wrong decision be undone, and what does it cost?

I suggest ranking actions on two axes: can it be reversed, and what does a mistake cost? Reversible, cheap actions can be left to the agent. Irreversible or expensive ones need a human approval gate. That gate isn’t an admission that the agent falls short; it’s a deliberate split of authority. Where the gate sits can change over time, too. As the records show the agent is reliable on a given type of action, you can pull the gate back.

3. Which tools can it reach, and under which identity?

Every tool an agent can call is a list of everything it can do. An agent running with a human user’s permissions can make every mistake that user could. You need a separate service identity, only the tools it needs, and the narrowest permissions that work. The July 2026 release of the Model Context Protocol helps here: method and tool names now travel in HTTP headers, so a gateway can see which tool is being called and apply policy without opening the request body.

4. Did you define “correct” before writing the agent?

An agent project without acceptance criteria is a demo that never ends. Before writing the agent, build a small evaluation set from real examples: for this input, which output is right, which is acceptable, which is wrong? That set becomes the basis for acceptance testing and for regression testing after every prompt change. On outsourced projects it belongs on the list of deliverables.

5. Does every run leave a trace?

When an agent does something wrong, the first question is “why?” To answer it you need, for every run, a record of the input, the tools called, what they returned, the model’s output and the cost. Those records are the raw material of incident response; without them every investigation is guesswork. There’s a second benefit: the trace shows what each task costs, which makes the budget conversation concrete.

6. Does it touch personal data?

On 12 March 2026 Türkiye’s data protection authority, KVKK, published guidance on agentic AI systems. According to the legal summaries, it expects organisations to have a data-governance framework and risk assessment covering their use of agentic AI, clear responsibilities between the parties processing data, human oversight designed in from the start, privacy by design and by default, and staff who understand what these systems do with data. Each of those maps onto one of the questions above. If your agent processes personal data, write that mapping down. It’s the first document an auditor will ask for.

If you serve the EU there’s one more item. The AI Act’s transparency obligations were not postponed by the new regulation. An agent that corresponds directly with people has to tell them they are dealing with an AI system.

7. What happens when you switch it off?

This is the question asked least. When the agent fails, when its cost jumps unexpectedly, or when the model provider changes something, who takes over the work? I expect every agent to have a written fallback: if a rule-based robot can do the same job, that robot should be on standby; if not, the work should drop into a human queue. Who holds the off switch, and which signal triggers the decision to use it, should be written down as well.

If the answer is “we don’t know”

If the answer to any of these seven is “we don’t know”, you aren’t running an agent in production. You’re running a pilot in production. That’s fine, as long as everyone knows it’s a pilot. The trouble starts on the day a pilot is budgeted like a product and audited like one.