AI agentification services for digital transformation

AI agentification is the step after digitisation and automation: software agents that read context, choose the next step and act through the same applications, APIs and back-office systems people use, within limits a person has set. In Europe it is arriving on rails that regulation is already laying (digital identity wallets, structured e-invoices, interoperable public services) and under an AI Act that requires logging and human oversight for high-risk uses. Whether an agent helps or hurts depends mostly on digital engineering: where it sits in the journey, which tested APIs it may call, and where a person approves what it does.

What does AI agentification actually mean?

Most large organisations have been through two waves already. Digitisation moved forms, records and approvals into systems. Automation wired those systems together with fixed rules: workflows, integrations, robotic process automation. Both waves assume someone knew every path in advance.

Agents drop that assumption. An agent gets a goal, looks at the context it is allowed to see, picks a tool (an API call, a search, a form it can submit), checks the result and decides what to do next. Agentification is the deliberate move of specific processes up the ladder below, one decision type at a time.

An agent with no reliable records and no working integrations has nothing to act on. At the top, an agent handles a defined class of decisions by itself while people set the limits, sample the output and own the exceptions.

Not every process should climb to the top. Gartner’s advice is that organisations “can start by using AI agents when decisions are needed, automation for routine workflows and assistants for simple retrieval” (Gartner, June 2025). The same release warns about “agent washing”: assistants, RPA and chatbots rebranded as agents without substantial agentic capabilities.

What is changing in government, business and society?

The three arenas move at different speeds, but they increasingly run on shared rails: verified digital identity, structured data exchange and one set of EU rules for AI.

Government and the public sector

The EU’s Digital Decade programme sets 2030 targets of 100% online access to key public services and 100% access to secure electronic identification recognised across the EU (Decision (EU) 2022/2481). The European Digital Identity Regulation requires Member States to provide EU Digital Identity Wallets to citizens by the end of 2026 (European Commission). And since 12 January 2025, the Interoperable Europe Act has required public administrations to carry out interoperability assessments when they introduce new or revised requirements for trans-European digital public services (Interoperable Europe). An identity attribute from a wallet can be checked automatically by an agent; a scanned PDF cannot.

The constraints are just as concrete. The AI Act treats as high-risk certain AI used to give access to essential public services, AI in migration, asylum and border control, and AI in the administration of justice (European Commission). The Digital Omnibus on AI, published in the Official Journal on 24 July 2026, fixed the dates: rules for these Annex III systems apply from 2 December 2027, and rules for AI embedded in regulated products from 2 August 2028 (European Parliament; AI Act Service Desk). The obligations include activity logging, documentation and appropriate human oversight. For public bodies that points agents towards preparing cases, routing requests and drafting replies inside the citizen portal, with a named official taking the decision.

Business and the enterprise

In 2025, 20.0% of EU enterprises with 10 or more employees used AI technologies, up from 13.5% in 2024 (Eurostat). Among large enterprises the share was 55.03% (Eurostat).

Structured exchange is doing the groundwork here too. Romania has required B2B e-invoicing since 1 January 2024 (European Commission), and under the EU’s VAT in the Digital Age package, digital reporting requirements apply to cross-border B2B transactions from 1 July 2030 (European Commission). Once every invoice is a structured record, matching, exception handling and supplier queries become realistic work for an agent.

Gartner predicts that 33% of enterprise software applications will include agentic AI by 2028, up from less than 1% in 2024. It also predicts that over 40% of agentic AI projects will be canceled by the end of 2027 “due to escalating costs, unclear business value or inadequate risk controls” (Gartner). Both can come true at once; for planning, the second matters more.

Society and citizens

In 2025, 32.7% of people aged 16 to 74 in the EU used generative AI tools (Eurostat). A Special Eurobarometer from early 2026 found that 80% of citizens think AI development should be carefully regulated, even if developers face some constraints (European Commission). The AI Act’s transparency rules apply from 2 August 2026: people should know when they are talking to a machine (AI Act Service Desk). In a digital product that is design work: a visible label, a link to where an answer came from, and a way to reach a person.

What has to be true before agents work in a large organisation?

Agents fail in predictable ways, and few of the failures are about the model. An agent clicks through a portal screen that changed in the last release, calls an internal API with an administrator’s token, leaves a customer in a queue nobody watches, or retries a failing call until the cloud invoice arrives. Each has a known engineering fix, cheaper before go-live.

Redesign the journey before adding the agent

Start from the journey, not the model. For a supplier query, a permit application or a returns request, map every step: what the agent reads, what it may change and where it hands over. When it passes a case to a person, that person should see what the agent saw, what it tried and why it stopped, so the customer or citizen is never asked to start again.

APIs and microservices are the agent’s tools

An agent acts through tools, and those tools should be tested, versioned APIs, not screen-scraping. A microservice with a clear contract (“create return”, “check order status”, “book an inspection slot”) gives the agent a small, predictable action, validated on the server. Version tool contracts like any other API, so a change in the order service cannot quietly change what the agent does. If you expose tools through Model Context Protocol (MCP) servers, the scoping questions stay the same whatever sits behind them; we work through one case in Snowflake, Databricks and BigQuery MCP servers: governed access.

Keep the model replaceable

The model is one component of the agent, and it should be replaceable. Put model calls behind your own interface, so each use case can run on the model that fits its accuracy, latency, cost and data-residency needs: a model from providers such as OpenAI, Anthropic, Google (Gemini) or Mistral AI, a cloud service such as Azure OpenAI, or an open-weight model such as Meta’s Llama run in your own environment. Frameworks such as LangGraph help with orchestration, but the evaluation set still decides, and it runs again whenever the model changes.

Integration with the systems of record

Real actions land in ERP, CRM and ITSM platforms, for example SAP, Salesforce or ServiceNow. An agent that raises a purchase order or closes a ticket is an integration and needs the same design, testing and change control as any other. Put a service layer you own between the agent and the system of record, so business rules, validation and retries live in tested code rather than in a prompt.

Identity and permissions

Interactive agents should act as the signed-in user, so permissions and audit trails behave exactly as they do for that person. Unattended agents get their own narrow identity, with only the scopes their job needs. A shared service account that can write everywhere turns a small mistake into an incident.

Human checkpoints in the product UI

Approvals belong in the product, not in an email thread. Design the approval step as a screen in the portal, the back-office application or an agent console, showing the proposed action and the evidence, with approve, edit and reject. Put these checkpoints where an error would travel furthest: payments, changes to customer records, decisions about citizens. Every action that changes a record should be logged and, where the business allows it, reversible.

Evaluation, observability and run

Before go-live, build an evaluation set of real requests with agreed outcomes and run it in the delivery pipeline on every change of prompt, model, tool or API version; a failing evaluation should block a release like a failing test. Log every request, tool call, model version, approval and result, and trace them across services. After launch the agent needs application management like any production system: monitoring, incident handling, an improvement backlog and a regular review of the cases it handed to people.

Cloud, cost and security

Agents retry, poll and explore. Give each one its own budget, timeouts and rate limits from the first pilot, so the business case is measured rather than assumed. Treat everything an agent reads (an email, a web form, an uploaded document) as untrusted input, because text can carry instructions that try to steer it; narrow tools and approved actions limit the damage.

Clean, governed data underneath

Agents also need clean, governed data underneath: records they can trust, with clear owners. That is a data platform question in its own right (see Data & AI).

How Duces Digital approaches AI agentification

Our view

Duces is a boutique technology consulting firm organised as a partnership, with three divisions: Data & AI, Digital, and Enterprise Apps & Platforms. AI agentification is the key service of our Digital division: we design, build and run AI agents inside digital products, customer and citizen journeys and business processes. We see agents as a new layer of the digital product and build them like the rest of the software: tested, versioned, observable, and owned by people who answer for the outcome. We stay model-agnostic: the model is chosen per use case and can be swapped without rebuilding the agent.

Our method

Our work follows one lifecycle: assess, design, build, deploy and manage, on-prem or on-cloud. For agentification we run it in five phases, each ending with an exit check.

1. Assess journeys and processes. Pick the requests and decision types worth giving to an agent, map the systems, APIs and permissions they touch, and agree how far up the ladder each should go.
2. Design the agent, its tools and the human checkpoints. Define what the agent may do, the API contracts it calls, the identity it runs as, and the approval screens where a person decides.
3. Build agents, APIs and integrations. Build the agent and the microservices it uses as tools, integrate them with the systems of record, and put the agent into your web, mobile, commerce or back-office applications.
4. Prove with evaluation sets and a pilot. Run the evaluation set in the pipeline, pilot with named users on one journey, and compare the results with how the work is handled today.
5. Deploy, run and evolve. Deploy on-prem or on-cloud, monitor every action, and run and improve the agent under application management. Then take the next journey.

Who delivers it

AI agentification is delivered by our Digital division, by the same teams that design, build and run web applications, microservices and eCommerce platforms. The agent, its tools and the screens where people approve its work are built and run together.

What you get

Routine requests are handled faster, and a person still decides the exceptions. The agent prepares the case and routes what it cannot settle to a specialist.

Self-service is available around the clock in the channels you already run: the customer portal, the mobile app, the storefront or the citizen service desk, with no separate chatbot bolted onto the side.

Actions can be traced and, where the process allows, undone: you see which agent did what, with which tool and model version, and who approved it.

Agents and the services behind them run on-prem or on-cloud, alongside the applications they serve. The people who design an agent are the people who run it: the seasoned professionals delivering your work are actual partners of the firm, accountable for the result.

If you are choosing the first journeys to hand to an agent and want them built, tested and run properly, talk to the people who build it.