By Mirte Pruppers, project leader at Rewire.

For years, prompt engineering advice has followed a familiar pattern:

Simple prompts? Use plain language.
Complex prompts? Use structured formats like XML or YAML.

The reasoning seems intuitive. As instructions become more hierarchical, nested, and rule-heavy, a format with explicit structure should help the model understand the relationships between different parts of the prompt.

XML tags look like they should make things clearer:

1
2
3
4
5
6
7

<rules>
    <policy>
        <condition>
        ...
        </condition>
    </policy>
</rules>

Compared to:

1
2
3
4
5

## Rules

### Policy

- If the condition is...

The XML version feels more precise. But there is a hidden cost: every tag is a token. And tokens are money. So we tested a simple question:

Does the additional structure provided by XML, YAML, and JSON actually justify the extra token cost?

And so we ran an experiment.

The experiment

We compared six different prompt formats:

• Plain English
• Markdown
• XML
• YAML
• JSON
• Key-value format

The goal was not to find a universal "best prompt format". Instead, we wanted to isolate one specific question:

How much does the representation format itself affect token usage and reliability?

To keep the comparison fair:

• The underlying instructions were identical.
• Only the formatting style changed.
• The same model was used throughout.
• The same tasks were evaluated.

The benchmark used:

• Model: gpt-4o-mini
• Four tasks with increasing complexity
• 10 examples per task and format

The tasks were:

1. Simple classification
   A straightforward classification task with a small number of rules.
2. Complex policy compliance
   A hierarchical policy evaluation task with multiple categories and nested decision rules.
3. Expense anomaly reasoning
   A multi-step reasoning task requiring the model to identify suspicious expense patterns.
4. Bulk expense audit handbook
   A substantially larger prompt, included in our token benchmark.

The expectation was:

• Simple tasks → plain English should perform well.
• Complex hierarchical tasks → XML/YAML might justify the overhead.

The data did not support that assumption.

The results

Finding 1: XML's structure consistently used more tokens

The strongest pattern from the benchmark was simple: XML used more tokens every time.

Across all four scenarios, XML was the most expensive option. The most interesting result was the second experiment: policy compliance complexity.

This was intentionally designed as the scenario where XML should shine. The task involved:

• nested rules
• multiple policy categories
• conditional logic
• hierarchical instructions

If there was ever a case where XML's explicit structure should have paid off, this was it. Well, it didn't. XML consumed 36% more tokens than the cheapest alternative. And it did not provide a reliability improvement.

Finding 2: Plain English and Markdown were the unexpected winners

The most consistent performers were not the heavily structured formats. They were the simplest ones:

• Plain English
• Markdown

Across all four tasks, these formats were effectively tied for lowest token usage. More importantly, they did not sacrifice reliability.

In two out of the four experiments, English and Markdown achieved the same 100% success rate as XML. This suggests something important about modern language models: the model already understands structure.

A human may look at:

1
2
3
4
5

<instruction>
    <rule>
        Reject claims above $500
    </rule>
</instruction>

and think: "That structure makes the relationship clearer."

But the model may simply see additional tokens describing a relationship it could already infer from:

1
2
3
4
5

## Instruction

### Rule

Reject claims above $500.

The explicit tags are not necessarily adding intelligence. They are adding text.

Finding 3: JSON was the most ambiguous result

JSON produced the most complicated results. It was generally middle-of-the-pack for token usage. However, its reliability numbers were less impressive in some tests, particularly the complex policy task. But this result needs caution: a benchmark is only as good as its measurement.

The two 0% success results are suspiciously clean. A true failure rate of 100% is possible, but it is also possible that the validator was too strict. For example, the model might return:

1
2
3

{
  "decision": "approve"
}

inside a Markdown code block:

1
2
3
4
5

```json
{
  "decision": "approve"
}
````

A strict parser using:

would reject this. But a human would likely consider the response correct. So the conclusion is not:

JSON is unreliable.

Instead, the more accurate conclusion is:

JSON formatting results require better validation before making strong claims.

This is actually one of the most interesting follow-up areas for the experiment.

What does this mean for prompt engineering?

The three practical takeaways are simpler than expected.

#1. Use Markdown or plain English by default.

For system prompts:

• clear headings
• bullet points
• short sections
• explicit instructions

are probably the best default. For example:

1
2
3
4
5
6
7
8
9

## Role

You are an expense review assistant.

## Rules

- Never invent missing information.
- Flag suspicious expenses.
- Explain your reasoning.

This style is:

• cheap
• readable
• easy to maintain
• understood well by modern models

#2. Do not use XML/YAML just because the prompt is complex.

Complexity alone is not a reason to add more syntax. A common assumption is that more structure helps the model reason.

Our results suggest a more nuanced view: More structure helps humans organize information, but the model may not need that structure expressed as additional tokens.

The model already learned patterns from enormous amounts of structured and unstructured text. Adding XML tags may simply duplicate information that was already obvious.

#3. Use structured formats when the output needs structure.

This does not mean XML, YAML, and JSON are useless. They are still valuable when the output needs to be consumed by another system. Examples:

• API responses
• database inserts
• workflow automation
• tool calls

If your application requires:

1
2
3
4

{
  "customer_id": 123,
  "risk_score": 0.87
}

then JSON is the right choice.

The lesson is not:

"Never use structured formats."

The lesson is:

"Do not pay the token cost of structured input unless it provides a real benefit."

Limitations

This experiment has at least three important limitations.

#1. One model

• The benchmark only used: gpt-4o-mini
• Different models may behave differently.
• A larger reasoning model may benefit more from certain structures.
• A smaller model may struggle more with ambiguous formatting.
• More models are needed before making broader claims.

#2. Small sample size

Each test used:

• 4 tasks
• 10 examples per format

The XML pattern is interesting because it appeared consistently across all four tasks. However, smaller differences between formats should not be overinterpreted.

#3. Reliability measurement

The benchmark measured whether outputs passed validation. That is useful, but incomplete. Future experiments should include:

• human evaluation
• semantic similarity scoring
• LLM-based grading
• reasoning quality assessment

A format could cost more tokens but produce better answers. Cost alone is not the whole story.

The bigger lesson

The most interesting result was not that XML was expensive. Everyone expected XML to use more tokens. The surprising part was this:

The extra tokens did not buy better results.

At least for this benchmark, the additional structure from XML did not improve reliability enough to justify its cost. A 30% token premium barely registers when testing ten requests. It looks different in an application serving thousands or millions of them. Our benchmark gives us no reason to routinely pay that premium for XML. Markdown and plain English were cheaper, easier to work with and, in these tests, just as reliable.

That is enough for us to keep things simple until the data tells us otherwise.

Agents reward organisations that ask harder questions first.

The organisations getting compounding value from agentic AI share one trait: they invested in getting the foundations right before scaling.

We've built agent systems across financial services, energy, telecom, and public sector, from early proofs of concept to production systems running at scale. We've seen what separates the deployments that deliver from the ones that don't.

Let's find the answers for your situation

-By Otto Gori, Lead Cloud Engineer & Engagement Manager at Rewire.

To say that data sovereignty – i.e. owning and controlling your data and making sure that there’s no unauthorized third-party access – is top of mind would be an understatement. In the first of a series of articles, I discuss the constraints and technology options to achieve data sovereignty while still enjoying the benefits of Generative AI.

The data sovereignty challenge

Consuming Generative AI at enterprise scale creates inherent complexity and tension between the data governance of your industrial secrets and what this new tool brings as capability to your company.

While consumer AI interfaces rely on shared API endpoints with "unknown" data retention or use by third party companies like OpenAI, Anthropic and so forth, enterprise architectures require strict data isolation, zero-retention guarantees, and precise lineage tracking.

The central thesis of modern AI architecture is straightforward: Enterprises do not necessarily need to build foundation models from scratch to achieve full data sovereignty.  By abstracting the intelligence layer from the underlying data hosting layer, organizations can maintain absolute administrative cryptographic and operational control over their proprietary assets while leveraging managed foundation models.

So problem solved? Not quite. That’s because there are a bunch of requirements that constrain data governance. Let’s review some of the most critical ones.

The “non negotiables” of production-grade data governance

Production readiness requires moving beyond raw API calls to robust control planes.

The first pillar of control is network perimeter isolation. Enterprise AI solutions must route inference prompts and fine-tuning artifacts through private link endpoints, preventing third-party telemetry or sensitive payload traffic from traversing the public internet.

The second pillar centers on zero data retention (ZDR) and cryptographic boundaries. Model providers must operate strictly as stateless processors. Customer prompts, context windows, and retrieval-augmented generation (RAG) embeddings must never be used to train foundational weights or stored in persistent provider logs. Furthermore, customer-managed encryption keys (CMEK) ensure that fine-tuned weights and vector embeddings remain unreadable to the platform provider at rest.

The third pillar is cloud agnosticism. Relying on proprietary toolchains creates strategic vulnerabilities. A resilient architecture decouples model invocation from business logic, treating large language models as interchangeable processing units behind unified API gateways.

But before we go agnostic, which solutions out there follow these principles, and you can easily interface with? Data sovereignty after all is not strictly defined by where your models run, but by who controls the compliance, encryption keys, network routes, retention logs and the physical location of the datacenters.

An overview of common technology solutions – and pointers on how to choose

While self-hosted open-source models (e.g., Llama, Mistral) on dedicated GPU clusters offer maximum theoretical control, they carry significant operational overhead. AWS Bedrock, Google Cloud Vertex AI, and Azure Foundry together control roughly 70% of the European hyperscale market, so your engineering team is almost certainly familiar with one or more of them. They provide the fastest path to production because they allow enterprises to apply existing governance policies, identity management (IAM), and network perimeters to foundation models without maintaining bare-metal infrastructure. They also greatly reduce the engineering challenge of implementing this solution in-house. Not to mention the very attractive price of experimentation when comparing with the acquisition of expensive hardware.

Rather than evaluating or recommending a single platform, this overview presents the primary enterprise options as reference. Each offers distinct governance models and isolation configurations; selecting the optimal solution depends entirely on your organization’s unique regulatory mandates and existing cloud footprint.

Amazon Bedrock

Implements a serverless API paradigm centered on strict data boundary enforcement. Prompts and completions are rendered statelessly and can be configured for zero content logging or model training by third-party model providers. Through AWS PrivateLink, inference calls remain entirely within the customer’s Amazon VPC. Fine-tuning jobs for models like Meta Llama or Amazon Titan run inside, isolated compute environments, encrypted with customer-managed AWS KMS keys.

Google Cloud Vertex AI

Provides integrated enterprise governance through Private Service Connect and VPC Service Controls. It allows organizations to deploy Gemini models alongside custom open-weight architectures within a controlled security perimeter. Vertex AI enforces strict zero data retention policies for enterprise contracts and integrates natively with Cloud KMS, guaranteeing that prompt histories and customer embeddings remain isolated within the enterprise boundary.

Azure Foundry

Enterprise-grade orchestration across Azure OpenAI Service and open-source model catalog offerings. By anchoring infrastructure in Azure Virtual Network private endpoints and Microsoft Entra ID role-based access control, organizations prevent data exposure. Azure  Foundry ensures that customer data is never used to train global base models, while enabling fine-tuning, RAG indexing in Azure AI Search, and prompt evaluation under strict data loss prevention policies.

Figure 1. A comparative matrix of the three most common solutions

Choosing the right platform usually comes down to where your data already lives and which models your workloads demand, but in a nutshell, this is a quick reference if you are still in doubt:

Choose AWS Bedrock if: Your application architecture is already heavily invested in AWS. Bedrock's serverless approach makes model swapping painless via unified APIs, and its PrivateLink integration is rock-solid for strict VPC isolation. Bedrock shines when you want to experiment with different model providers (like Anthropic vs. Meta) without rewriting your orchestration logic or managing compute instances.

Choose Google Cloud Vertex AI if: You require deep integration with BigQuery to leverage advanced data analytics or want to fine-tune open-weight models alongside Google’s Gemini family. Vertex AI’s VPC Service Controls provide unmatched security perimeters if you are already handling complex data pipelines on GCP, though configuring the security boundaries requires rigorous IAM hygiene.

Choose Azure Foundry if: Your enterprise relies heavily on the Microsoft ecosystem (Azure VNets, Microsoft Entra ID) or requires direct access to OpenAI’s frontier models within a dedicated enterprise tenant. Azure makes identity management and Role-Based Access Control (RBAC) seamless through Entra ID, making it a favorite for security teams to audit end-user access to RAG pipelines.

Conclusion

Achieving true data sovereignty in enterprise Generative AI is ultimately an architectural discipline, not a product feature. While Amazon Bedrock, Google Vertex AI, and Azure Foundry offer the stateless invocation, private perimeters, and encryption capabilities required for compliance, no managed platform will solve governance for you out of the box. Sovereign AI isn't about where the intelligence is hosted—it’s about who holds the keys to the kingdom.

And as a personal hint: use KMS Keys for your kingdom =)

Sources - If you would like to extend your research, start here.

Google Cloud Vertex AI

• Google Cloud Generative AI Privacy & Data Governance Commitment. Google’s explicit contractual commitments regarding data ownership, non-retention of prompts/responses for base model training, and adherence to enterprise privacy standards.
• Vertex AI Data Governance & Security Controls. How Vertex AI protects the complete AI life cycle—from training to runtime inference—within enterprise perimeters.
• Vertex AI Dataset Encryption with CMEK. Technical implementation of Customer-Managed Encryption Keys (CMEK) via Google Cloud KMS for encrypting Vertex AI datasets and model artifacts.
• VPC Service Controls Documentation. Mitigating data exfiltration risks by enforcing private network boundaries and isolating multi-tenant Google Cloud resources.

Amazon Bedrock

• Amazon Bedrock Security, Privacy, and Responsible AI. Amazon Bedrock’s core data policy, establishing that customer inputs and outputs are never shared with model providers or used to train base foundation models.
• [Data Protection in Amazon Bedrock (User Guide). Encrypting custom models, agent sessions, and knowledge bases using AWS Key Management Service (KMS) customer-managed keys.
• Amazon Bedrock VPC & PrivateLink Setup. Establishing private VPC network connectivity through AWS PrivateLink to execute inference requests without exposing traffic to the public internet.

Azure Foundry / Azure OpenAI

• Data, Privacy, and Security for Models Sold in Microsoft Foundry. Proof that prompts, generated content, and fine-tuning data in Azure Foundry are strictly customer-isolated, double-encrypted at rest, and omitted from base model training.
• Data, Privacy, and Security for Azure Foundry Agent Service. Specific data isolation rules for stateful entity memory, RAG integrations, and custom agent tool execution.
• Security Features in Azure Content Understanding & Foundry Tools. Implementing Virtual Network (VNet) private endpoints, Microsoft Entra ID role-based access control (RBAC), and Customer-Managed Keys (CMK) within Azure AI infrastructure.

Agents reward organisations that ask harder questions first.

The organisations getting compounding value from agentic AI share one trait: they invested in getting the foundations right before scaling.

We've built agent systems across financial services, energy, telecom, and public sector, from early proofs of concept to production systems running at scale. We've seen what separates the deployments that deliver from the ones that don't.

Let's find the answers for your situation

By Öykü Yıldırım, data scientist at Rewire.

AI agents are often stateless: they solve each task in isolation and carry nothing forward. For example, a support agent resolves a ticket, then meets the next one having forgotten the fix it just found. Your AI system never gets better at the job it does repeatedly.

Memory changes all that.

The question then for an engineering team is what's the ROI, how much cost and efforts to plough into it, and how best to engineer the memory.

Let's dive in.

Quantifying the impact of memory

To find out what memory is really worth, we ran one support agent that resolves a ticket by reasoning through it and querying a live database, two ways: with memory and without, holding everything else constant.

The workload was 56 real tickets processed in four sequential batches, which let us watch performance change as experience built up rather than reading a single snapshot. We scored each answer with independent LLM judges that we validated against an expert's ratings rather than trusting them blind, and tracked the cost of every task directly. We tested five memory designs: from a memoryless baseline through four memory schemes of rising sophistication, each adding one layer of capability in terms of memory saving, deduplication and memory file structure, the findings held.

The more revealing figure is how that gain behaved over time. In the first batch of tickets the best memory design was barely ahead of the memoryless baseline; by the fourth it led by close to 8 points on our primary measure, and by nearly 10 on the stricter of the two judges.

Put simply, performance improved as the system learned from experience.

The best part is that cost, measured by token usage, stayed small. Memory added under 10% to the cost of a task in every design we tried, and about 7% for the design that performed best. That’s because the bill is dominated by the large fixed context every request carries - several hundred thousand tokens – not by the memory itself.

Figure 2. How five memory designs relates to three performance dimensions.

Three lessons from the experiment

In addition to making the case for memory, our experiments provided some guidance for how to maximise the impact of memory - several of them running against the intuition the AI tooling itself often encourages. Summing up:

• Memory helps, and it helps by accumulating contextual knowledge. And the payoff compounds: it is small at the start, when there is little history, and largest once experience has accumulated.
• Cleverer is not automatically better. It is tempting to tinker with memory to make it smarter - summarise raw cases, merge the similar ones, distil them into general rules, and so on. Each step is reasonable, and each throws information away. In reality, the simplest memory design, which keeps past cases in full and looks them up by similarity, was the most accurate of the five and the best at holding on to what it had learned. On the other hand, and counter-intuitively, the most elaborate architecture, which digests cases into general rules, costs the most to run and performed even less well than an agent with no memory at all.
• A tidy memory is not the same as a good one. The winning memory design filled up within the first seventeen tickets and simply dropped its oldest entries as it went, yet came out ahead. Managing memory efficiently and using it effectively are different things. Optimising the first does not deliver the second.

The bottom line

• Memory is a high-return, low-cost upgrade. Under 10% more per task buys a quality gain that compounds over time. For agents doing repetitive work, the small incremental cost is more than offset by the increased quality.
• When designing memory, start simple. In practice the simpler memory designs wins. Fund elaborate memory machinery only once you have evidence it will pay off.
• Insist on a no-memory baseline, and track quality over time. Without a baseline you cannot tell a memory that helps from one that underperforms. And performance on launch-day says little about whether the system holds over time.
• Optimise the context, not the memory module. The dominant cost is the fixed context each request carries. That, rather than the memory design, is where the real savings sit.

From our work with clients who deal with a vast amount of data and complex workflows with extensive internal loops, we’ve found time and again that memory turns a capable model into a system that gets better at its job the longer it runs, and it does so for a fraction more. The trap is assuming that cleverer memory means better memory. The real discipline is knowing what to keep, and getting that right, reliably, is what turns a promising demo into a system a business can depend on.

Agents reward organisations that ask harder questions first.

The organisations getting compounding value from agentic AI share one trait: they invested in getting the foundations right before scaling.

We've built agent systems across financial services, energy, telecom, and public sector, from early proofs of concept to production systems running at scale. We've seen what separates the deployments that deliver from the ones that don't.

Let's find the answers for your situation

Enterprise AI deployments often follow a recognisable pattern. A pilot performs well but the move from pilot to production stalls. A common explanation is that the model is not yet capable enough, and that the remedy is to wait for the next generation. Recent research suggests this explanation is incomplete. In a recent publication from Princeton University, “Towards a Science of AI Agent Reliability” (Link.) Sayash Kapoor, Arvind Narayanan and colleagues draw a distinction that is easy to overlook in procurement decisions: the difference between capability and reliability.

Capability and reliability are not the same metric

Capability describes how often a system produces the correct result. Reliability describes the nature of its failures rather than their frequency. A system may be highly capable, correct in the majority of cases, and still be difficult to depend on, because its errors are inconsistent, hard to anticipate, or hard to reverse.

To make reliability measurable, the paper borrows four properties from fields with a history of managing failure, notably aviation and nuclear engineering.

• Consistency refers to producing the same output for the same input.
• Robustness refers to performance under imperfect conditions and tool failures.
• Calibration refers to a system signalling uncertainty rather than answering with unwarranted confidence.
• Safety refers to failures being recoverable rather than catastrophic. Aviation, for reference, targets on the order of one catastrophic error per billion flight hours.

The empirical results are the most relevant part for practitioners of enterprise AI. Across fourteen models over eighteen months, the authors report that capability (also referred to as ‘accuracy’ in the paper) improved rapidly while reliability improved only modestly. In their data, each additional point of accuracy was associated with a gain of roughly a fifth to a third of a point of reliability. Consistency was among the weakest dimensions, with the same request producing a correct outcome in an estimated thirty to seventy five percent of runs depending on the model. To put that in perspective: at 75% consistency, a process fed identical inputs five times running will return the same answer every time in just 32% of cases, assuming independence. Stretch it to ten runs and the figure falls to 7.5%.

Depending on the Enterprise AI use case is, such variation may well be unacceptable. Yet it is rarely visible in a single demonstration.

Figure 1. Figure from Kapoor, Narayanan et al., “Towards a Science of AI Agent Reliability” (2026, arXiv:2602.16666), licensed under CC BY 4.0. The shallow slopes are the key point: reliability rises only about 0.18 to 0.33 points – depending on the benchmark - per point of accuracy. https://arxiv.org/abs/2602.16666

Why reliability, rather than capability, may govern the business case

The value of an agent depends heavily on how much supervision it requires. Larger gains appear to lie in work that can run with limited oversight, and a system is usually granted that degree of autonomy only once its behaviour is consistent enough to be trusted over time.

On this reading, an agent that completes a task correctly nine times out of ten but fails unpredictably in the tenth case may still require review of all ten. This gapis one of the reasons why many pilots perform well in demonstration yet comparatively few reach production at scale.

It also helps explain why waiting for a more capable model often disappoints. Capability and reliability do not appear to advance at the same rate. A new model is likely to be more capable, but the available evidence gives little reason to expect a proportional gain in reliability.

How reliability might be engineered

The paper's framing points toward reliability as something built around a model rather than obtained from it. This reflects our own experience on client projects..

• Measure reliability as much as accuracy. A single successful demonstration provides limited evidence. Running the same task repeatedly and examining behaviour across consistency, robustness, calibration and safety gives a more representative picture than an average score. The dimensions hidden by a one-off run are often the ones that later surface in production.
• Constrain the scope. Reliability is generally easier to achieve on a narrow task with clearly defined success criteria than on an open-ended one. Broad scope tends to be where failures become unpredictable.
• Decompose long tasks. Agentic systems appear to degrade abruptly rather than gradually as tasks grow longer and larger. Breaking a long run into shorter, verifiable steps helps keep the system within the range where it remains dependable.
• Add verification and fallbacks. Independent checks on outputs, guardrails and graceful degradation can convert an unnoticed failure into a detected one. Human review can then be concentrated where an error would be costly, rather than applied uniformly.
• Evaluate procurement on reliability. Vendor comparisons that reward benchmark capability alone may select for the wrong property. Consistency and calibration deserve explicit weight.

This approach is not new. It reflects established practice in safety critical industries, where the objective is not a flawless component but a system that stays dependable when a component is not. Organisations that run regulated production environments, trading systems or industrial plants will recognise the logic, since it is broadly how those environments are already managed.

Public attention will continue to track capability, and capability is likely to keep improving. The harder question for industrial adoption may be reliability. On current evidence, the advantage lies less with the organisation that holds the most capable model, and more with the one that can turn a capable model into a system dependable enough to run with limited supervision.

Capability can be bought; reliability has to be built.

About the author

Dr. Philipp Diesinger is a data science executive with over 15 years of global experience driving AI-powered transformation across industries. He has led high-impact initiatives at Boehringer Ingelheim, BCG, and Rewire, delivering measurable value through advanced analytics, GenAI, and data strategy at scale.

Agents reward organisations that ask harder questions first.

The organisations getting compounding value from agentic AI share one trait: they invested in getting the foundations right before scaling.

We've built agent systems across financial services, energy, telecom, and public sector, from early proofs of concept to production systems running at scale. We've seen what separates the deployments that deliver from the ones that don't.

Let's find the answers for your situation

Recent AI agent performance research show that AI agents now achieve near 100% success on tasks that take a human under 4 minutes, but less than 10% success on tasks over 4 hours. In other words: the longer the task, the less reliable agents are. The issue appears to be structural: making the agent smarter will not fix it. Redesigning tasks, however, can.

Figure 1. Model success rate vs Human completion time. Source: Kwa et al. (July 2026). Measuring AI Ability to Complete Long Software Tasks. https://arxiv.org/pdf/2503.14499

Why generalist AI agents fail, especially in biopharma

In the context of the biopharma, building one generalist agent and load it with context across regulatory, scientific, commercial, and clinical domains is inefficient. A generalist agent trying to manage regulatory compliance, synthesise scientific evidence, and sketch reimbursement pathways will hallucinate or won't go deep enough. It might be 90% right on average, but you'll never know which 10% is wrong. And one flawed reasoning step will cascade through the entire chain. In biopharma, that's an unacceptable risk.

Software engineering learned this lesson in the 2000s. Giant monolithic codebases are hard to debug or to scale. The answer was microservices, with independent modules, deployment, and validation.

The same logic now applies to agentic AI in biopharma.

The orchestration answer: specialised agents with human decision gates

Translating the logic of microservices into agentic AI systems for biopharma, the orchestration approach gives this:

• Small agents, each excellent at one narrow task. A regulatory agent that only checks compliance. A science agent that only reviews evidence. A market agent that only models reimbursement.
• Each agent can be validated independently. You can test the regulatory agent against known regulatory outcomes. You can't test a generalist agent against "everything.“
• Guardrails are built into the architecture. Validation gates between agents. If the regulatory agent flags a problem, the pipeline stops before the market agent wastes cycles on an invalid pathway. Guardrails must be structural, as we explain here.
• Humans stay in the loop at the right moments. Not reviewing every output, but sitting at decision gates between phases. The architecture defines where human judgment matters most.
• It scales. Need to add a new domain? Add a new agent. Need to improve regulatory accuracy? Retrain one agent, not the whole system.

While most industries adopting agentic AI have to build governance frameworks from scratch, biopharma already has this. The decision-gate architecture — specialised agents operating within human checkpoints — maps directly onto how pharma already works. Regulatory affairs, medical affairs, clinical development, market access: each function already has defined review cycles, sign-off requirements, and clear accountability structures. This is the multi-agent orchestration model.

Why pharma is the perfect domain for agentic systems

Developing a single drug takes 10-15 years and $1-2.6B. A significant share of that cost is coordination overhead: re-reading, re-synthesizing, waiting for reviews, reconciling conflicting inputs across functions. An analysis of 270 life sciences workflows (1200 tasks) and found that 75-85% contain tasks that could be automated or augmented by AI agents, potentially freeing 25-40% of organizational capacity.

Take medical content creation. A single piece of promotional content currently moves through approximately seven sequential review cycles across medical, legal, regulatory, and localisation. Each reviewer waits for the previous one. Average cycle: six to eight weeks.

Under an orchestrated multi-agent model, a drafting agent produces the initial version. Medical accuracy agents and regulatory compliance agents run in parallel. Localisation agents adapt for local markets simultaneously. Humans approve at two defined gates: after the initial draft and after the final review. The cycle collapses from weeks to days, while the quality controls remain intact.

The same logic applies across the pipeline: pharmacovigilance monitoring, regulatory submission drafting, protocol design, site selection, KOL mapping. In each case, the opportunity is not to replace human judgement, but to remove the coordination overhead that delays it.

The gap will be measured in pipeline years

Enterprise application of agentic systems is growing at nearly 50% compound annually, and the microservices approach is becoming the dominant architecture for AI agents. For pharma, organisations that get the orchestration right will soon gain years of pipeline advantage.

Philipp Diesinger leads the pharma Practice Area at Rewire.

Sources:

• Gartner Hype Cycle for Agentic AI, 2025 | Gartner Newsroom, Aug 2025
• SagaLLM, arXiv 2503.11951 | Du et al., "Improving LLM Reasoning with Multi-Agent Debate," arXiv 2305.14325
• IDC; PMC (NCBI PMC6372467)
• McKinsey, "Reimagining Life Science Enterprises with Agentic AI," Sep 2025
• Bain & Company, "How to Make Your Drug Launch a Success"
• DiMasi et al. (2020), PubMed 32125404
• GMP Pros / Farseer (2023)
• Grand View Research, Pharmaceutical Regulatory Affairs Market, 2024

Agents reward organisations that ask harder questions first.

The organisations getting compounding value from agentic AI share one trait: they invested in getting the foundations right before scaling.

We've built agent systems across financial services, energy, telecom, and public sector, from early proofs of concept to production systems running at scale. We've seen what separates the deployments that deliver from the ones that don't.

Let's find the answers for your situation

By Femke van Engen, project lead, and Olivier Lamers, data scientist at Rewire.

Let’s play make-believe.

You manage enthusiastic non-technical teams who interact regularly with technical teams. For example, to improve workflows, flesh out new ideas, or analyse data. The problem is that there is only so much your technical teams can handle.

Still, you'd like to improve collaboration between technical and non-technical teams and, more broadly, accelerate your organisation's innovation capabilities.

Well, vibe coding might be part of the answer.

But what, exactly, is vibe coding?

What vibe coding means

Put simply, vibe coding means describing what you want in plain natural language, and an AI tool turns it into working software in minutes. No coding skills needed. No briefing an engineer who sends you back to the drawing board until you’ve figured all the unknowns. No begging a tech lead whose next free slot is in six weeks.

The result? An idea that would have taken a few sprints to render visible can become a working prototype in less than an hour.

Still on the fence? Check out this web app that was put together by a senior exec in one of our recent vibe coding workshop. She had never coded before, yet built a Property Selector in under an hour — a desktop app that automatically scores, filters, clusters and assigns scraped real estate listings into optimised scout-visit schedules, helping investment analysts identify the best opportunities and plan field visits more efficiently.

The best part: no particular setup was needed. Just a Lovable account and her laptop.

Figure 1. From vague idea to detailed prototype in under an hour.

Why vibe coding accelerates innovation

The practical benefits of translating an idea into a working prototype that fast are straightforward:

• Speed to output. An idea becomes something your non-technical teams can show and react to in minutes instead of weeks. The distance between thinking and doing collapses.
• Better conversations. A working prototype beats a slide deck or a written brief. Fuzzy ideas become concrete. Requirements and variables are better defined. Your non-technical teams are better prepared and the translation gap from the person who understands the business problem to the person who can render it in code is vastly reduced.
• Lower cost of being wrong. If the concept does not hold up under scrutiny, your non-technical team finds out in an afternoon, not after a development sprint.

What vibe coding won't do

Ok. We’ve convinced you since you made it this far. There are, however, a couple of caveats.

First of all, the constraint now is conceptual, rather than technical: the quality of what you generate depends almost entirely on the quality of your thinking before you start. Define what you want (and don’t want!) clearly and a single well-constructed prompt will produce something impressive. Let’s be very clear: the best results tend to come from spending roughly 80% of the available time on definition and scoping, and 20% on generation. The AI is not a substitute for thinking.

Second, do not rush to make your IT team redundant. Vibe coding is great to build prototypes running on a laptop that overheats when you have more than 3 browser tabs open. But don’t expect to put this in production within hours. There are simply too many issues that need to be addressed first: cybersecurity, data sovereignty, governance, integration with legacy systems, to name a few. So stay friends with your technical team, and use vibe coding to improve the quality of the discussions between your technical and non-technical teams.

The main takeaway

Vibe coding won't replace good thinking, or your technical teams. It will show you and your business teams, whether an idea is worth their time, faster than ever.

The best prototypes start with the best thinking.

You don't need to know or write code. You need to describe what you want in terms that are clear to an AI. That skill alone will let you and your teams turn ideas into working prototypes, improve discussions with technical teams, and accelerate innovation.

Find out more

Across banks, insurers, and asset servicers today, a similar picture emerges. On the one side, AI initiatives running in parallel without ever being absorbed into daily operations. On the other, initiatives that reliably create value. The difference between the two groups lies in the approach.

Let's focus on asset servicing in particular, because the industry tends to assume regulation is what holds it back. The opposite is closer to the truth: Fund administration, transfer agency, and the middle office already run as a sequence of controlled steps with defined owners, defined inputs, and a check at every gate. That structure is precisely the one in which AI, and agentic AI in particular, does its best work.

When AI really delivers in asset servicing

Before examining what separates success from failure, it is worth starting with what actually works. Across our projects, three factors consistently drive AI value.

• First, a clear goal inside the process. For example, "cut the time from a complete subscription pack to a cleared investor onboarding by half, so the transfer agency team can absorb a fund launch without adding headcount" is a goal a team can tackle immediately, and one against which success can be measured. On the other hand, "use AI in onboarding" will fail on both counts.
• Second, the right data, understandable and reliable. Asset servicing sits on rich, structured data: investor records, subscription and redemption flows, fund accounting ledgers, custody positions, prospectuses, etc. Here the regulated firm has a quiet advantage, because reporting obligations and audit requirements have often already forced a level of data discipline that less regulated industries lack.
• Third, results where the decision is made. In asset servicing the point of decision usually sits at a control gate: the oversight check before a NAV is released, the four-eyes review on a payment, the compliance sign-off on a new investor. Good AI does prepares the decision inside the tool the reviewer already uses, surfaces the exceptions that need a human eye, and leaves a trace of how it got there.

Where these three elements come together, impact emerges that is measurable and scalable. And it is the pattern behind the AI work that actually takes hold in regulated operations.

The structure is the advantage

It helps to be precise about why asset servicing is such fertile ground. A fund's operational life runs as a chain of distinct stages, each with its own rules, its own data, and its own responsible owner. Investor onboarding and the KYC and AML checks that gate it. Subscription and redemption processing. NAV calculation and the oversight that validates it. Reconciliation across custody and accounting. Regulatory and investor reporting at the end. Between every stage sits a handover and, almost always, a control.

This is the same architecture that multi-agent AI systems are built around. Specialized components do focused work within clear boundaries, and they hand off to one another at defined points. A single, monolithic AI asked to do everything across this chain tends to drift and to hallucinate. Specialized agents with narrow remits and clean handover points behave far more predictably, which is exactly what a regulated process requires.

The regulatory apparatus that asset servicers sometimes experience as friction is, in this light, scaffolding. The four-eyes principle is human-in-the-loop, written into the operating model long before anyone spoke of agents. AIFMD and MiFID II define who is accountable for what. DORA, which has applied to financial entities across the EU since January 2025, has pushed firms to map their operational and ICT dependencies in detail, which is the same map an agent needs to act safely. The EU AI Act, now phasing in, asks for exactly the documentation, oversight, and traceability that a well-run fund administrator already produces for its regulators. Under the CSSF and its peer supervisors, governance is not a feature to be bolted on. It is already in the building.

The constraint, then, is coordination: getting the right specialized capability to the right step, with a clean handover and a human at the gate. That is an architecture problem, and it is one this industry has been solving by hand for decades.

Tap or click a milestone for the detail behind it.

Each rule that once felt like a constraint installed a guardrail: accountability, audit trail, human oversight, a mapped environment, delegation control. That is the exact control set agentic AI needs, and the regulated firm already operates it.

Four patterns that mark successful delivery

However different mandates and maturity levels may be, the firms making visible progress attend to the same four themes.

1.  Enable the right people, not only the technologists

A common assumption is that AI competence is mainly a matter of hiring more data scientists. In practice the larger leverage comes from the people who truly know the work: the fund accountants, the transfer agency officers, the oversight and quality managers who can tell a genuine exception from a benign one. They carry the context that makes an AI initiative take off. They know how a redemption will be processed, which investor data can be trusted, and where a NAV error occurs. When these people are deliberately enabled, in short, practice-oriented sessions on real cases, a technical experiment becomes a working tool. The reliable pattern is a tandem: domain expert and AI specialist working side by side, domain knowledge flowing into requirements, AI results flowing back into the process. The time from idea to first productive version typically halves.

2.  Focus on a few, genuinely viable use cases

The portfolios that work are deliberately lean. Three to five use cases with visible leverage on core processes, each with a named owner and clear success criteria. Equally important is the discipline of finishing things. When a pilot has exhausted its potential, it is closed deliberately, and it makes room for the next. An illustrative picture from operations: rather than spreading effort across onboarding, reconciliation, and reporting at once, a successful team concentrates on one defined step, for example pre-checking incoming subscription documents against the legal requirements and flagging what is missing before it reaches the reviewer. The benefit shows up less in a single headline number than in a team that is noticeably relieved and a queue that clears more consistently.

3.  Anchor AI directly where decisions are made

The last mile decides between AI introduced and AI in use. The firms that are consistent here build AI into the workflow: a flag inside the existing oversight tool rather than another screen, clear accountability for who acts on it, and a defined escalation for when the model is unsure. AI then becomes not an add-on but an extra pair of eyes and hands at the gate. An illustrative picture from oversight: a NAV review assistant recalculates key positions in parallel, compares them against the administrator's output, and presents only the discrepancies that exceed the NAV error threshold, with the underlying data attached. The reviewer still releases the NAV, as always. They simply see sooner where to look.

4.  Treat AI as a product, not a project

Software projects have an end. AI systems do not. Successful firms give their AI systems the attention they give any production capability: a responsible owner, an operating concept, regular quality checks, versioning, and cost control. The effect is that the system stays reliable as inputs and processes change, and trust in it grows steadily. This is familiar territory for a regulated firm, because model validation, ongoing monitoring, and documented oversight are already part of the vocabulary.

Agentic AI as the natural next step

These four patterns lead naturally to where the technology is heading. The most useful way to picture agentic AI in asset servicing is a small set of specialized agents working in parallel within human decision gates. The point is that this division of labour decouples the depth of analysis from the number of people available to do it. Routine, synthesis, and scale move to the agents. The human contribution concentrates where it has always created the most value, in judgment at the gate.

Between every stage sits a control. Agents do the preparation, a person decides at the gate, and nothing passes without an audit trail. This is the decision-gate architecture, drawn straight from the way fund administration already works.

Notice the feedback loop: regulation shapes the architecture of the AI system; the system, in turn, strengthens compliance — producing a more complete audit trail, faster.

It's not the tools. It's the capability

The firms that stay ahead build capability rather than acquire tools. Teams that understand and steer AI. Data products that are maintained and trusted. Systems that run in everyday operations instead of a test environment. And an operating logic that secures the value tomorrow as well. The most regulated corner of finance does not need to wait for the rest of the industry to work out how to govern AI. It already knows. The handover points, the four-eyes checks, the audit trail, and the documented oversight that can feel like weight are, for agentic AI, the blueprint.

Footnotes

* A further milestone reinforces the onboarding gate: the EU's 2024 anti-money-laundering package. Its single, directly applicable Anti-Money Laundering Regulation (AMLR) takes effect across the EU on 10 July 2027, and a central supervisor, AMLA, has been operational in Frankfurt since July 2025. In agent terms it sharpens a guardrail the chart already shows: verified, structured client due-diligence data and one harmonised standard for what must be checked before an investor passes.

About the authors

Dr. Philipp Diesinger is a data science executive with over 15 years of global experience driving AI-powered transformation across industries. He has led high-impact initiatives at Boehringer Ingelheim, BCG, and Rewire, delivering measurable value through advanced analytics, GenAI, and data strategy at scale.

Dorthe van Waarden leads organizations in creating tangible impact by developing and implementing advanced algorithmic systems. She is passionate about combining the power of humans with the potential of AI to achieve the best outcomes and doing this in a responsible way. Dorthe holds a MSc in Mathematics from the University of Amsterdam.

Agents reward organisations that ask harder questions first.

The organisations getting compounding value from agentic AI share one trait: they invested in getting the foundations right before scaling.

We've built agent systems across financial services, energy, telecom, and public sector, from early proofs of concept to production systems running at scale. We've seen what separates the deployments that deliver from the ones that don't.

Let's find the answers for your situation

By Marcel Mol and Job van Zijl, Rewire.

Companies looking to scale agentic systems quickly run into a limitation: AI is only as intelligent as the knowledge it can draw upon. While LLMs let organisations open up sources that were previously hard to utilize, such as PDFs and Word documents, the fact is that businesses aren’t documented the way they need to be to fully leverage today’s technology. 

Three problems arise:

• Knowledge is tacit, internalized by employees and never written down.
• Knowledge is imperfect, with out-of-date information, discrepancies between sources, and so on.
• Knowledge is missing.

To solve these problems, we introduce the knowledge engine methodology, underpinned by a broader vision: the codified enterprise. This is how we define the winning organisations of tomorrow — where knowledge compounds rather than churns, and where agents can be deployed reliably at scale.

How the codified enterprise develops asymmetric competitive advantage

Today, organisational expertise is siloed by design: it belongs to individuals and teams, rather than the organisation as a whole. People do most of the work, and AI augments specific processes as and when needed.

Agentic AI flips is set to flip the equation around, with agents doing most of the operational work, while people oversee strategy, creativity, and edge cases. But this is only possible with a governed knowledge layer that agents and humans can query and maintain. Knowledge — rather than churning out of the door whenever someone leaves — becomes a compounding asset.

Think about what this means operationally: the codified enterprise can onboard a new agent in hours rather than weeks, because the knowledge it needs exists in structured form. It can scale a process across markets with improved institutional memory. It can respond to regulatory change by updating a knowledge graph and propagating the change systematically, rather than hoping that the right people update the right documents and that those documents get read.

The non-codified competitor, meanwhile, is still dependent on specific individuals, still recreating knowledge from scratch, still debugging agents that behave inconsistently because their prompts are patching over gaps in an unstructured information environment.

Building tomorrow’s codified enterprise

Building a codified enterprise starts with addressing three challenges:

• Making all knowledge machine-readable. The issue here is that most business knowledge lives in people’s heads, unstructured documents, or process tooling that agents cannot access. None of it is governed or current.
• Knowledge extraction taking human effort. Even where documentation exists, it is incomplete and ungoverned. The decision rules that experienced people apply intuitively — when to escalate a claim, how to handle an exception — are rarely written down. Structuring this for autonomous agent use still requires people to validate and sharpen what gets captured.
• Knowledge is never finished. Processes change. Thresholds shift. Regulations evolve. A knowledge system not designed to update continuously will decay — and agents grounded in stale knowledge become unreliable.

The knowledge engine methodology uses process documentation as input, and allows expert validation of the acquired knowledge. But there’s more to it. As a video is worth more than a thousand words, check out the video demo below. You’ll see how the knowledge engine in action, as well as:

• How knowledge can be extracted following an expert-defined ‘knowledge skeleton’, applied to building a knowledge graph from internal policy documents
• How to the extracted knowledge can be visualized, and gaps and contradictions can be made visible
• How AI can help closing these gaps by suggesting fixes, which can be approved or changed by experts

Watch the video

Rewire LIVE started with a vision: to create an interactive event where participants from the business community could openly share their experiences with AI. Last week in Amsterdam, business leaders and innovators gathered to make that vision a reality.

The result exceeded expectations.

Through debates, workshops, and keynotes, attendees collectively explored what it takes to move from experimentation to meaningful impact with AI.

The next stage in the evolution of AI: introverted thinking

The day opened with a thought-provoking keynote by Wouter Huygen, Rewire CEO, who explored the paradox at the heart of Generative AI: it’s both incredibly smart and... surprisingly stupid.

Figure 1. ChatGPT, waxing digital.

So... “Are we building on shaky foundations and quicksand?”

His answer: no. Despite the limitations of current models, there is a massive opportunity overhang. With emerging toolkits and rapid innovation, today’s GenAI represents years of transformative potential.

Perhaps one of the most surprising insights was the emergence of “introverted thinking” in reasoning models – enabling transformers to refine their internal states before producing an answer. This leads to higher performance on complex reasoning tasks with smaller, more energy-efficient models. As Wouter noted, the bitter lesson of AI has, in the end, often tasted quite sweet.

Successful AI adoption: it’s all about speed and leadership

Moderated by Joe van Burik, tech editor at BNR Nieuwsradio, participants were invited to respond to a series of questions that revealed how they view AI adoption in corporate environments. Key insights included:

• 87% disagreed with the idea that AI is “just hype.”
• Most agreed that AI adoption should start with leadership, ideally from the boardroom down.
• The consensus was that it’s better to be a fast follower than a slow pioneer. Speed consistently emerged as a key success factor.

Participants then debated a range of topics, from build vs. buy strategies to regulation and productivity gains.

Figure 2. Joe submitting the audience to intense questioning.

The discussion concluded with a deceptively simple question:

What do you hope AI will bring to society?

We’ll leave you to ponder the resulting word cloud (below).

Figure 3. Every cloud has a silver lining.

Data & AI in action with hands-on workshops

The day featured four practical workshops, each tackling a different dimension of AI transformation:

• From GenAI demo to production, by Simon Koolstra & Mirte Pruppers (Rewire). Participants began with a GenAI demo and collaborated to solve the challenges that typically emerge when moving from demo to production. The exercise highlighted a hard truth: many can build demos, but scaling is where most fail.
• Reimagine your business with data, by Freek Gulden & Nanne van’t Klooster (Rewire). This session challenged participants to reimagine their businesses once data is viewed as a value stream rather than operational exhaust.
• Decentralized data leadership, by Daniëlle Bourgondië (PGGM Investments). Daniëlle led a lively discussion on what it takes for business domains to take ownership of their data and drive AI strategies. As she aptly put it: “This is not optimization. It’s reimagination.”
• Roles & responsibilities in digital transformation, by Sam van Kesteren (Royal Terberg Group) & Ties Cabo (Rewire). This workshop explored how to align business and technical roles & responsibilities to overcome some of the trickiest barriers to large-scale transformation.

Figure 4. Working out GenAI best practices: One team. One dream.

Real-world lessons from the corporate world

The day wouldn't have been complete without guest speakers detailing how AI is transforming their organizations from the inside out.

• Maarten Kramer, Chief Data Officer at a.s.r., demonstrated how agentic AI is reshaping complex insurance processes, starting with personal injury claims involving over two million documents annually. Their approach: treat AI agents like employees, with training, performance management, and oversight.
• Tim Prins, Program Director of Autonomous Operations at KPN, outlined how KPN aims to deliver the best customer service in Europe while halving costs. Agentic AI plays a central role in this ambitious transformation.
• Finally, Winifred Andriessen (VP of AI Excellence Center at KPN), Maarten Kramer (Chief Data Officer at a.s.r.), and Laura Brandwacht (Partner at Rewire) joined a panel discussion on AI’s impact on the workforce. They explored how AI is reshaping roles, the need for reskilling and upskilling, the enduring importance of human skills, and the leadership and culture required to make AI a success. The conversation underscored that AI transformation is as much about people and leadership as it is about technology.

Figure 5. Not just talk: the people who are transforming businesses with AI.

Key takeaway

The day concluded with drinks and conversations went well into the evening. Reflecting on the event, two themes stood out. First, we’re at a pivotal moment in history where the playbooks for leveraging AI are still being written. Second, collaboration is key. Joining forces is the best way to reimagine your business.