The world has changed — artificial intelligence (AI) is reshaping business faster than most can adapt

The rise of large language models and agentic AI has created unprecedented scale, speed, and complexity. Enterprises are moving from static infrastructures to hyperplexed, distributed, and autonomous systems. Organizations are pouring more than $400 billion into AI infrastructure, a wave expected to generate more than $2 trillion in new value. But without resilience at the core, that value remains at risk.

As innovation accelerates, new risks emerge just as quickly. Security is lagging behind transformation. Data is exploding, with nearly 40% year-over-year growth across hybrid and multicloud environments. Regulations are tightening, and ransomware and AI-powered attacks are multiplying. The result: Resilience now defines competitive advantage.

Resilience drives velocity

Resilience isn’t just recovery. It’s also the foundation of sustained innovation. Traditional recovery models were built for yesterday’s outages, not today’s AI-driven disruptions, which unfold in milliseconds. In this world, recovery is table stakes. True resilience means that every system runs on clean, verifiable data, and it restores trust when it’s tested.

The most resilient organizations are also the fastest movers. They adopt emerging technologies with confidence, recover with speed and integrity, and innovate at scale. Resilience has evolved from a safety net to the engine of enterprise speed and scalability.

Introducing resops, the model for next-generation resilience

Resops, short for resilience operations, is an operating model that unifies data protection, cyber recovery, and governance into a single intelligent system. It creates an ongoing loop that monitors, validates, and protects data across hybrid and multicloud environments, enabling organizations to detect risks early and recover with confidence.

By integrating resilience into every layer of operations, resops transforms it from an isolated function into a proactive discipline — one that keeps businesses secure, compliant, and ready to adapt in the AI era.

To learn more about ResOps, read “ResOps: The future of resilient business in the era of AI.” 

---

Enterprise Application Integration (EAI) and modern iPaaS platforms have become two of the most strategically important – and resource-constrained – functions inside today’s enterprises. As organizations scale SaaS adoption, modernize core systems, and automate cross-functional workflows, integration teams face mounting pressure to deliver faster while upholding strict architectural, data quality, and governance standards.

AI has entered this environment with the promise of acceleration. But CIOs are discovering a critical truth:

Not all AI is built for the complexity of enterprise integrations – whether in traditional EAI stacks or modern iPaaS environments.

Generic coding assistants such as Cursor or Claude Code can boost individual productivity, but they struggle with the pattern-heavy, compliance-driven reality of integration engineering. What looks impressive in a demo often breaks down under real-world EAI/iPaaS conditions.

This widening gap has led to the rise of a new category: Vertical AI Development Agents – domain-trained agents purpose-built for integration and middleware development. Companies like CurieTech AI are demonstrating that specialized agents deliver not just speed, but materially higher accuracy, higher-quality outputs, and far better governance than general-purpose tools.

For CIOs running mission-critical integration programs, that difference directly affects reliability, delivery velocity, and ROI.

Why EAI and iPaaS integrations are not a “Generic Coding” problem

Integrations—whether built on legacy middleware or modern iPaaS platforms – operate within a rigid architectural framework:

• multi-step orchestration, sequencing, and idempotency
• canonical data transformations and enrichment
• platform-specific connectors and APIs
• standardized error-handling frameworks
• auditability and enterprise logging conventions
• governance and compliance embedded at every step

Generic coding models are not trained on this domain structure. They often produce code that looks correct, yet subtly breaks sequencing rules, omits required error handling, mishandles transformations, or violates enterprise logging and naming standards.

Vertical agents, by contrast, are trained specifically to understand flow logic, mappings, middleware orchestration, and integration patterns – across both EAI and iPaaS architectures. They don’t just generate code – they reason in the same structures architects and ICC teams use to design integrations.

This domain grounding is the critical distinction.

The hidden drag: Context latency, expensive context managers, and prompt fatigue

Teams experimenting with generic AI encounter three consistent frictions:

Context Latency

Generic models cannot retain complex platform context across prompts. Developers must repeatedly restate platform rules, logging standards, retry logic, authentication patterns, and canonical schemas.

Developers become “expensive context managers”

A seemingly simple instruction—“Transform XML to JSON and publish to Kafka”—
quickly devolves into a series of corrective prompts:

• “Use the enterprise logging format.”
• “Add retries with exponential backoff.”
• “Fix the transformation rules.”
• “Apply the standardized error-handling pattern.”

Developers end up managing the model instead of building the solution.

Prompt fatigue

The cycle of re-prompting, patching, and enforcing architectural rules consumes time and erodes confidence in outputs.

This is why generic tools rarely achieve the promised acceleration in integration environments.

Benchmarks show vertical agents are about twice as accurate

CurieTech AI recently published comparative benchmarks evaluating its vertical integration agents against leading generic tools, including Claude Code.
The tests covered real-world tasks:

• generating complete, multi-step integration flows
• building cross-system data transformations
• producing platform-aligned retries and error chains
• implementing enterprise-standard logging
• converting business requirements into executable integration logic

The results were clear: generic tools performed at roughly half the accuracy of vertical agents.

Generic outputs often looked plausible but contained structural errors or governance violations that would cause failures in QA or production. Vertical agents produced platform-aligned, fully structured workflows on the first pass.

For integration engineering – where errors cascade – this accuracy gap directly impacts delivery predictability and long-term quality.

The vertical agent advantage: Single-shot solutioning

The defining capability of vertical agents is single-shot task execution.

Generic tools force stepwise prompting and correction. But vertical agents—because they understand patterns, sequencing, and governance—can take a requirement like:

“Create an idempotent order-sync flow from NetSuite to SAP S/4HANA with canonical transformations, retries, and enterprise logging.”

…and return:

• the flow
• transformations
• error handling
• retries
• logging
• and test scaffolding

in one coherent output.

This shift – from instruction-oriented prompting to goal-oriented prompting—removes context latency and prompt fatigue while drastically reducing the need for developer oversight.

Built-in governance: The most underrated benefit

Integrations live and die by adherence to standards. Vertical agents embed those standards directly into generation:

• naming and folder conventions
• canonical data models
• PII masking and sensitive-data controls
• logging fields and formats
• retry and exception handling patterns
• platform-specific best practices

Generic models cannot consistently maintain these rules across prompts or projects.

Vertical agents enforce them automatically, which leads to higher-quality integrations with far fewer QA defects and production issues.

The real ROI: Quality, consistency, predictability

Organizations adopting vertical agents report three consistent benefits:

1. Higher-Quality Integrations

Outputs follow correct patterns and platform rules—reducing defects and architectural drift.

2. Greater Consistency Across Teams

Standardized logic and structures eliminate developer-to-developer variability.

3. More Predictable Delivery Timelines

Less rework means smoother pipelines and faster delivery.

A recent enterprise using CurieTech AI summarized the impact succinctly:

“For MuleSoft users, generic AI tools won’t cut it. But with domain-specific agents, the ROI is clear. Just start.”

For CIOs, these outcomes translate to increased throughput and higher trust in integration delivery.

Preparing for the agentic future

The industry is already moving beyond single responses toward agentic orchestration, where AI systems coordinate requirements gathering, design, mapping, development, testing, documentation, and deployment.

Vertical agents—because they understand multi-step integration workflows—are uniquely suited to lead this transition.

Generic coding agents lack the domain grounding to maintain coherence across these interconnected phases.

The bottom line

Generic coding assistants provide breadth, but vertical AI development agents deliver the depth, structure, and governance enterprise integrations require.

Vertical agents elevate both EAI and iPaaS programs by offering:

• significantly higher accuracy
• higher-quality, production-ready outputs
• built-in governance and compliance
• consistent logic and transformations
• predictable delivery cycles

As integration workloads expand and become more central to digital transformation, organizations that adopt vertical AI agents early will deliver faster, with higher accuracy, and with far greater confidence.

In enterprise integrations, specialization isn’t optional—it is the foundation of the next decade of reliability and scale.

Learn more about CurieTech AI here.

In times of disruption, Agile leadership can help CIOs make better, faster decisions — and guide their teams to execute with speed and discipline.

When the first case of COVID hit my home city, it was only two weeks after I’d become president of The Persimmon Group. For more than a decade, I’d coached leaders, teams and PMOs to execute their strategy with speed and discipline.

But now — in a top job for the first time — I was reeling.

Every plan we had in motion — strategic goals, project schedules, hiring decisions — was suddenly irrelevant. Clients froze budgets. Team members scrambled to set up remote work for the first time, many while balancing small children and shared spaces.

Within days, we were facing a dozen high-stakes questions about our business, all with incomplete information. Each answer carried massive operational and cultural implications.

We couldn’t just make the right call. We had to make it fast. And often, we were choosing between a bunch of bad options.

From crisis to cadence

At first, we tried to lead the way we always had: gather the facts, debate the trade-offs and pick the best path forward. But in a landscape that changed daily, that rhythm broke down fast.

The information we needed didn’t exist yet. The more we waited for certainty — or gamed out endless hypotheticals — the slower and more reactive we became.

And then something clicked. What if the same principles that helped software teams move quickly and learn in real time could help lead us through uncertainty?

So we started experimenting.

We shortened our time horizons. Made smaller bets. Created fast feedback loops. We became almost uncomfortably transparent, involving the team directly in critical decisions that affected them and their work.

In the months that followed, those experiments became the backbone of how we led through uncertainty — and how we continue to lead today.

An operating system for change

What emerged wasn’t a formal framework. It was a set of small, deliberate habits that brought the same rhythm and focus to leadership that Agile brings to delivery.

Here’s what that looked like in practice:

Develop a ‘fast frame’ to focus decisions

In the first few months of the pandemic, our leadership meetings were a tangle of what-ifs. What if we lost 20% of planned revenue this year? What if we lost 40%? Would we do layoffs? Furloughs? Salary cuts? And when would we do them — preemptively or reactively?

We were so busy living in multiple possible futures that it was difficult to move forward with purpose. To break out of overthinking mode, we built a lightweight framework we now call our fast frame. It centered on five questions:

1. What do we know for sure?
2. What can we find out quickly?
3. What is unknowable right now?
4. What’s the risk of deciding today?
5. What’s the risk of not deciding today?

The fast frame forced us to separate facts from conjecture. It also helped us to get our timing right. When did we need to move fast, even with imperfect information? When could we afford to slow down and get more data points?

The fast frame helped us slash decision latency by 20% to 30%.

It kept us moving when the urge was to stall and it gave us language to talk about uncertainty without letting it rule the room.

Build plans around small, fast experiments

After using our fast frame for a while, we realized something: Our decisions were too big.

In an environment changing by the day, Big Permanent Decisions were impractical — and a massive time sink. Every hour we spent debating a Big Permanent Decision was an hour we weren’t learning something important.

So we replaced them with For-Now Decisions — temporary postures designed to move us forward, fast, while we learned what was real.

Each For-Now Decision had four parts:

1. The decision itself — the action we’d take based on what we knew at that moment.
2. A trigger for when to revisit it — either time-based (two weeks from now) or event-based (if a client delays a project).
3. A few learning targets — what we hoped to discover before the next checkpoint.
4. An agility signal — how we communicated the decision to the team. We’d say, “This is our posture for now, but we may change course if X. We’ll need your help watching for Y as we learn more.”

By framing decisions this way, we removed the pressure to be right. The goal wasn’t to predict the future but to learn from it faster. By abandoning bad ideas early, we saved 300 to 400 hours a year.

Increase cadence and transparency of communication

In those early weeks, we learned that the only thing more dangerous than a bad decision was a silent one. When information moves slower than events, people fill the gaps with assumptions.

So we made communication faster — and flatter. Every morning, our 20-person team met virtually for a 20-minute standup. The format was simple but consistent:

• Executive push. We shared what the leadership team was working on, what decisions had been made and what input we needed next.
• Team pull. Anyone could ask questions, raise issues or surface what they were hearing from clients.
• Needs and lessons. We ended with what people needed to stay productive and what we were learning that others could benefit from.

The goal wasn’t to broadcast information from the top — or make all our decisions democratically. It was to create a shared operating picture. The standup became a heartbeat for the company, keeping everyone synchronized as conditions changed.

Transparency replaced certainty. Even when we didn’t have all the answers, people knew how decisions were being made and what we were watching next. That openness built confidence faster than pretending we had it all figured out.

That transparency paid off.

While many small consulting firms folded in the first 18 months of the pandemic, Agile leadership helped us double revenue in 24 months.

We stayed fully staffed — no layoffs, no pay cuts beyond the executive team. And the small bets we made during the pandemic helped rapidly expand our client base across new industries and international geographies.

Develop precise language to keep the team aligned

As we increased the speed of communication, we discovered something else: agility requires precision. When everything is moving fast, even small misunderstandings can send people sprinting in different directions.

We started tightening our language. Instead of broad discussions about what needed to get done, we’d ask, “What part of this can we get done by Friday?” That forced us to think in smaller delivery windows, sustain momentum and get specific about what “done” looked like.

We also learned to clarify between two operating modes: planning versus doing. Before leaving a meeting where a direction was discussed, we’d confirm our status:

• Phase 1 meant we were still exploring, shaping and validating and would need at least one more meeting before implementing anything.
• Phase 2 meant we were ready to execute.

That small distinction saved us hours of confusion, especially in cross-functional work.

Precise language gave us speed. It eliminated assumptions and kept everyone on the same page about where we were in the process. The more we reduced ambiguity, the faster — and calmer — the team moved.

Protect momentum by insisting on rest

Agility isn’t about moving faster forever — it’s about knowing when to slow down. During the first months of the pandemic, that lesson was easy to forget. Everything felt urgent and everyone felt responsible.

In software, a core idea behind Agile sprints is maintaining a sustainable pace of work. A predictable, consistent level of effort that teams can plan around is far more effective than the heroics often needed in waterfall projects to hit a deadline.

Agile was designed to be human-centered, protecting the well-being and happiness of the team so that performance can remain optimal. We tried to lead the same way.

After the first few frenetic months, I capped my own workday at nine hours. That boundary forced me to get honest about what could actually be done in the time I had — and prioritize ruthlessly. It also set a tone for the team. We adjusted scopes, redistributed work and held one another accountable for disconnecting at day’s end.

The expectation wasn’t endless effort — it was sustainable effort. That discipline kept burnout low and creativity high, even during our most demanding seasons. The consistency of our rest became as important as the intensity of our work. It gave us a rhythm we could trust — one that protected our momentum long after the crisis passed.

Readiness is the new stability

Now that the pandemic has passed, disruption has simply changed shape — AI, market volatility, new business models and the constant redefinition of “normal.” What hasn’t changed is the need for leaders who can act with speed and discipline at the same time.

For CIOs, that tension is sharper than ever. Technology leaders are being asked to deliver transformation at pace — without burning out their people or breaking what already works. The pressures that once felt exceptional have become everyday leadership conditions.

But you don’t have to be a Scrum shop or launch an enterprise Agile transformation to lead with agility. Agility is a mindset, not a method. To put the mindset into practice, focus on:

• Shorter planning horizons
• Faster, smaller decisions
• Radical transparency
• Language that brings alignment and calm
• Boundaries that protect the energy of the team

These are the foundations of sustainable speed.

We built those practices in crisis, but they’ve become our default operating system in calmer times. They remind me that agility isn’t a reaction to change — it’s a readiness for it. And in a world where change never stops, that readiness may be a leader’s most reliable source of stability.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

機能志向から「振る舞い志向」へのパラダイムシフト

従来のソフトウェア開発において、仕様とは機能と画面の一覧であることが多くありました。どのボタンを押すとどのAPIが呼ばれ、どのデータがどのように更新されるかを、フローチャートや画面遷移図で記述するやり方です。このアプローチは、入力と出力が厳密に定義できる決定論的なシステムに対しては非常に有効でした。

ところが、LLMエージェントは本質的に確率的なシステムです。同じ質問をしても、生成される文章は毎回少しずつ異なりますし、状況の変化やメモリの内容、外部ツールからのレスポンスによっても振る舞いが変わります。このようなシステムに対して「すべての入力パターンと出力を網羅する仕様書」を書こうとすると、すぐに破綻してしまいます。結果として、「なんとなく賢いアシスタントを入れてみたが、どうなっていれば成功なのか分からない」という状態に陥りがちです。

そこで必要になるのが、機能ベースではなく振る舞いベースの仕様設計です。重要なのは「このエージェントはどんな人格・役割を持ち、ユーザーから見てどのように振る舞ってほしいのか」を言語化することです。専門用語をどの程度使うのか、どこまで踏み込んだ提案をしてよいのか、分からないときに黙り込むのではなくどう質問し返すのか、といった対話上の振る舞いに加え、どの外部ツールをどの状況で使ってよいのか、どこから先は必ず人間の承認を挟むのかといった、権限や責任に関するルールも仕様の一部になります。

プロダクトマネージャーは、これらを自然言語で記述された「行動指針」として定義し、それをプロンプトやシステムメッセージ、ポリシーファイルとして実装チームと共有していく必要があります。従来の要件定義書に、人格設計や対話ポリシー、ツール利用ルールといった新しい章が追加されるイメージです。

仕様書としてのプロンプトとポリシー設計

LLMエージェントにおいて、プロンプトは単なる「その場しのぎの魔法の呪文」ではなく、仕様書そのものに近い役割を果たします。とくにシステムプロンプトやロール定義、ツールの説明文などには、プロダクトマネージャーが考え抜いた行動ポリシーが反映されるべきです。

たとえば、カスタマーサポート向けのエージェントを設計する場合、「顧客の感情を先に受け止める」「自社に非がある可能性を軽々しく認めないが、決して責任転嫁もしない」「法的な判断を伴う表現は必ず保留し、人間の担当者にエスカレーションする」といったニュアンスをプロンプトに埋め込むことができます。ここで有効なのは、抽象的な美辞麗句ではなく、実際にあり得る会話例を含めた具体的な指示です。良い応答例と悪い応答例を並べ、どちらを目指すかを明示することで、モデルの振る舞いは大きく変わります。

さらに、ツール利用ポリシーも仕様として明文化する必要があります。どのツールは読み取り専用なのか、どのAPIを呼ぶ際には必ずユーザーに確認を求めるのか、連続して外部サービスを叩きすぎないためのレート制限はどう設計するのかといった点を、プロダクトマネージャーがビジネス側・セキュリティ側の利害を調整しながら決めていきます。その結果は、エージェントのランタイム設定とプロンプト両方に反映されます。

このように、プロンプトとポリシーは「コードではない仕様」でありながら、システムの振る舞いを強く規定します。したがって、プロンプトの改訂は仕様変更そのものであり、変更管理やレビューのプロセスが必要です。誰がどの目的でプロンプトを更新し、それによってどの指標がどのように変化したのかを記録しておくことは、品質とガバナンスの両面から重要になっていきます。

評価・ロールアウト・組織体制の再設計

振る舞いベースの仕様を設計できたとしても、それが「良いかどうか」をどう評価するかという問題が残ります。LLMエージェントでは、一件一件の応答の正しさだけでなく、タスク全体としての成功率、ユーザーが節約できた時間、誤動作によるリスクの頻度と重大性など、複数の指標を組み合わせて判断する必要があります。

実務上は、まず限定されたユースケースを対象に、パイロットユーザーを相手にベータ運用を行うのが現実的です。その際、ユーザーにはなるべくそのままのログを残してもらい、どの場面でエージェントが役に立ち、どの場面でイラッとさせられたのかを定性的・定量的に分析します。プロダクトマネージャーは、その結果をもとに、プロンプトやツール構成、インターフェースを繰り返し調整していきます。評価指標としては、タスク完了までに必要なステップ数の減少、手動対応へのエスカレーション率、ユーザーの主観的満足度などが使われることが多くなります。

ロールアウトの戦略も、従来の機能リリースとは少し異なります。LLMエージェントは、権限の範囲によってリスクが大きく変わるため、最初は「提案のみ」「ドラフトのみ」といった控えめなモードで導入し、一定の実績が確認できてから「自動実行」の範囲を広げていく段階的なアプローチが望ましいでしょう。その過程で、ユーザー教育や利用ポリシーの明文化も並行して進める必要があります。

最後に、組織体制についても触れておく必要があります。LLMエージェントのプロダクトには、モデルのチューニングやプロンプト設計に詳しいメンバー、ドメイン知識を持つ業務側のメンバー、セキュリティ・法務の観点からリスクを見られるメンバーなど、多様な専門性が求められます。プロダクトマネージャーは、その橋渡し役として、技術とビジネスとガバナンスを統合する「翻訳者」のような存在になります。この新しい役割を自覚し、学び続けることが、LLMエージェント時代のPMに求められる最大の資質だと言えるでしょう。