The most useful thing IBM did at the Agentic AI Summit 2026 was not launch a product. It was name the unglamorous problems that decide whether an agent ever makes it past the demo: evaluation, reliability, security, interoperability, and legacy integration.

That matters for one reason. Most agentic AI you have seen this year works in a controlled demo and breaks the moment it touches real enterprise data, permissions, and systems of record. The gap between “it worked on stage” and “it runs in production, safely, every day” is where budgets quietly disappear.

The summit itself was hosted by Berkeley RDI at UC Berkeley on August 1-2, 2026. IBM did not give a plenary keynote or announce anything new there. Its major product news – watsonx Orchestrate, IBM Bob, Sovereign Core, Concert – had already landed at Think 2026 in May. What IBM sent to Berkeley instead was four researchers with four talks, and each one pointed at a different failure mode that stops agents from reaching production.

For a CIO, enterprise architect, or integration lead, that is the more valuable signal. Product launches tell you what a vendor wants to sell. A research agenda tells you what the same vendor privately thinks is still unsolved. This article breaks down what IBM put on stage, what it means for agentic AI architecture and AI governance in your environment, and what to do next if you are trying to move agents from pilot to production.

Here is what the summit signaled, section by section.

What IBM Actually Brought to the Agentic AI Summit

Bottom line: IBM showed up with research, not a roadmap. Four IBM researchers gave four technical talks on Sunday, August 2. There was no plenary keynote, no product launch, and no open-source release tied to the event.

That is worth saying plainly, because event recaps tend to inflate a vendor’s presence into news. The honest version is quieter and more useful. IBM used the summit to share work in progress on the parts of agentic AI that are genuinely hard – not the parts that demo well.

The product story had already happened three months earlier. watsonx Orchestrate, IBM Bob, Sovereign Core, and the Concert platform were announced at Think 2026 in May. Berkeley was not a launch venue. It was a room full of researchers comparing notes on why production agents still fail.

Here is who IBM sent, and what each talk was really about:

IBM speaker	Role	Talk	What it actually addresses
Ranjan Sinha	IBM Fellow, CTO & VP, watsonx Enterprise AI	Speaking the Same Language: NLIP for Agent Interoperability	Whether agents from different vendors and teams can talk to each other at all
Michal Shmueli-Scheuer	Distinguished Engineer, AI Evaluation, IBM Research	Ready for General Agents? Let’s Test It.	How you prove an agent is good enough to trust in production
Gosia Steinder	IBM Fellow, IBM Research	Beyond Harnesses: Platform Solutions for Agent Reliability, Security, and Efficiency	The platform controls (identity, permissions, isolation) an agent needs to run safely
Rahul Krishna	Senior Research Scientist, IBM Software Innovation Labs	ScarfBench: Can Agents Migrate Enterprise Java?	Whether agents can safely touch legacy code and core systems

Note the pattern. None of these talks is about making an agent look impressive. Every one is about what breaks after the demo ends: interoperability, evaluation, security, and legacy integration. The full program is public on the Berkeley RDI summit page.

Four talks, four different failure modes. Taken together, they map the distance between a working demo and a production system. The next section unpacks each one.

The Four Production Problems IBM’s Researchers Put on Stage

Bottom line: each IBM talk maps to a decision you have to make when you design agentic AI architecture for real workloads. Read them less as research abstracts and more as a checklist of what your architecture has to answer before an agent goes live.

1. Interoperability: can your agents even talk to each other?

Ranjan Sinha’s talk on NLIP (a natural-language interaction protocol) targets a problem most pilots never hit: the second agent. One agent calling one API is easy. The trouble starts when agents from different teams, vendors, and platforms have to coordinate, pass context, and hand off work.

Without a shared protocol, every agent-to-agent connection becomes custom integration code that someone has to own and maintain. That is how you rebuild the same integration debt you spent a decade trying to retire. For an integration lead, the practical question is simple: is your agent estate converging on open protocols, or quietly forking into point-to-point spaghetti?

2. Evaluation: how do you prove an agent is good enough to trust?

Michal Shmueli-Scheuer’s talk, Ready for General Agents? Let’s Test It., points at the gap that kills most production plans. A demo proves an agent can succeed once. Production requires proof that it succeeds reliably, on your data, within acceptable failure rates.

Most organizations cannot currently answer “how good is this agent?” with a number. They answer with a screen recording. That is not a basis for a go-live decision in a regulated or revenue-critical process. Before you scale an agent, you need a repeatable evaluation harness – test cases, benchmarks, and pass/fail thresholds – not a compelling demo.

3. Reliability and security: the platform underneath the agent

Gosia Steinder’s talk, Beyond Harnesses, makes the least glamorous and most important point. An agent is not just a model. It is a model wrapped in a platform that has to handle identity, permissions, state isolation, tool access, and observability. Get that platform wrong and you have shipped a well-spoken security incident.

This is where agentic AI security stops being abstract. An agent with broad, ungoverned access to your systems is a new class of insider risk – one that acts fast, at scale, and without a lunch break. The controls that matter are boring on purpose:

• Identity and least-privilege access for every agent, scoped like you would scope a service account.
• State and session isolation so one agent’s context cannot leak into another’s.
• Tool and action governance – an approval layer for anything an agent can execute.
• Observability and audit trails so you can reconstruct what an agent did, and why.

If you cannot produce an audit trail for an agent’s decisions, it is not production-ready. It is a liability with good manners.

4. Legacy integration: can agents safely touch core systems?

Rahul Krishna’s ScarfBench asks whether agents can migrate enterprise Java. Strip away the benchmark and the real question underneath is one every large enterprise faces: can an agent be trusted near the code and data that the business actually runs on?

This is the hardest test, because core systems are unforgiving. A hallucination in a chatbot is embarrassing. A hallucination in a payments migration is a board-level event. Benchmarks like ScarfBench exist precisely because “the agent seemed to handle it” is not good enough near mission-critical systems.

The pattern that matters

Put the four together and the message is clear. Production-grade agentic AI architecture is not one clever model. It is interoperability, evaluation, security, and safe integration – working as one system. IBM’s researchers were not showing off agents. They were showing the scaffolding that has to exist before an agent is safe to trust.

That scaffolding is a data and integration problem before it is an AI problem. Which is exactly the point of the next section.

Enterprise Impact: Why “After the Demo” Is a Data, Integration, and Governance Problem

Bottom line: agentic AI does not fail because the model is weak. It fails because the data is untrustworthy, the systems are not connected, and no one can govern what the agent does. Fix those three and the agent becomes useful. Skip them and a better model just fails faster.

This is the part vendors underplay, because it is not for sale as a feature. IBM’s research agenda quietly confirms it: interoperability, evaluation, and security are downstream of your data and integration foundation. An agent is only as good as what it is allowed to read, connect to, and act on.

An agent inherits every problem your data already has

Point an agent at fragmented data and it will confidently produce wrong answers – faster than any human could. AI-ready data is not a nice-to-have here; it is the precondition. If your reporting layer already shows three different numbers for revenue, an agent will pick one and act on it, and now the inconsistency has consequences.

The uncomfortable truth for most enterprises: the blocker is not the AI. It is years of data nobody fully trusts. That is the same problem that has haunted BI for a decade, now with an autonomous actor attached to it.

Integration decides whether the agent can do anything real

An agent that cannot reach your systems is a demo. An agent that can reach them without governance is a risk. The value lives in the middle – governed, well-defined connections through APIs and integration layers that the agent uses under clear rules.

This is why agent sprawl is really an integration story. Every new agent multiplies connections, permissions, and failure paths. Without an integration control plane, you are not scaling capability. You are scaling the number of things that can break at 2 a.m.

AI governance is the part that makes it safe to keep

AI governance is what turns a working agent into one you can defend to a regulator, an auditor, or your own board. It is not paperwork. It is the operating layer that answers four questions on demand:

Governance question	What it requires in practice
What is the agent allowed to do?	Scoped permissions and least-privilege access
What did it actually do?	Complete, tamper-evident audit trails
How do we know it is still behaving?	Ongoing evaluation and monitoring, not a one-time test
Who is accountable when it is wrong?	Clear ownership and an escalation path

A practical AI governance framework ties these together so that governance is enforced by the platform, not by hoping people follow a policy. If governance depends on good intentions, it is not governance. It is a wish.

The sequence that actually works

Put plainly, the order is not negotiable:

1. Trustworthy data first – a single version of the truth the agent can rely on.
2. Governed integration second – controlled, auditable access to systems.
3. Agents last – deployed on top of a foundation that can support them.

Most failed agentic AI projects run this backwards. They start with the agent, hit the data and integration wall, and stall. The organizations that succeed treat agentic AI as the last mile of a data and integration program – not the first move.

Gaps, Trade-offs, and Open Questions

Bottom line: the summit surfaced the right problems but did not solve them. Treat IBM’s talks as an honest problem statement, not a finished playbook. Here is what is still open – and where to keep your skepticism.

What the summit did not answer

The research was pointed, but it stayed at the level of problems and approaches. A few things were notably absent, and you should not fill the gaps with optimism:

• No production case studies. The talks covered protocols, benchmarks, and platform primitives – not “here is an agent running a regulated process at scale, and here is what it cost.” Approaches are not proof.
• No cost or economics story. Nobody put a number on what it takes to run governed agents in production. Evaluation, monitoring, and audit are ongoing operating costs, not one-time setup.
• No independent verification. As of publication, there is no independent tech-press or analyst coverage specific to IBM’s talks at this summit. The primary source is the program itself. So treat the details as accurate-but-thin, and confirm anything load-bearing against a second source.

The trade-offs nobody puts on a slide

Every control that makes an agent safe also makes it slower, costlier, or less autonomous. That tension is real, and pretending otherwise is how projects get oversold:

You want	It costs you	The honest read
Full autonomy	Control and auditability	Fully autonomous agents in critical paths are rarely worth the risk today
Tight governance	Speed and flexibility	Governance adds friction – budget for it rather than resenting it
Open interoperability	Vendor-specific optimization	Open protocols reduce lock-in but rarely match a single-vendor stack on day one
Rapid deployment	Data and integration readiness	You can move fast, or you can move on a shaky foundation – not both

The questions to ask before you believe any agentic AI pitch

Use these to pressure-test your own roadmap and any vendor who walks in the door:

1. Show me the evaluation. How do you measure this agent’s reliability on our data, and what is the acceptable failure rate?
2. Show me the audit trail. Can we reconstruct exactly what the agent did, and why, after the fact?
3. Show me the blast radius. What is the worst thing this agent can do if it goes wrong, and what stops it?
4. Show me the integration. What does this connect to, under what permissions, and who owns those connections?
5. Show me the running cost. What does governed operation cost per month, not just to build?

If a vendor – or an internal team – cannot answer these, the agent is not ready for production. It is a demo with a deployment date attached.

The realistic position

None of this means agentic AI is hype. It means the value is real but conditional. The condition is a data, integration, and governance foundation that most enterprises have not finished building. IBM’s researchers were honest about the hard parts. The mistake would be to hear the hard parts and assume someone else has already handled them for you.

Practical Next Steps

Bottom line: you do not need a summit-sized budget to act on this. You need to check whether your foundation can support agents before you deploy them. Start with a readiness pass, then sequence the work.

A 30-day agentic AI readiness check

Run this before you approve a single production agent. It is diagnostic, not a project – a week or two of honest assessment:

• ☐ Data trust audit. Pick one process you would hand to an agent. Can you produce a single, trusted source for the data it needs? If not, that is your first project – not the agent.
• ☐ Integration inventory. Map what the agent would need to connect to, and confirm each connection has a defined owner, defined permissions, and an API you control.
• ☐ Permission model. Decide how an agent gets least-privilege access, scoped like a service account, before it touches anything.
• ☐ Evaluation baseline. Define what “good enough” means in numbers for this use case – success rate, acceptable failure modes, and who signs off.
• ☐ Audit and rollback. Confirm you can log every agent action and reverse it. If you cannot roll it back, do not let it run unattended.

If most boxes are unchecked, the finding is not “we are behind on AI.” It is “we have a data and integration gap that AI just made visible.”

Sequence the work in the right order

Resist the pressure to start with the agent. The order that survives contact with production:

1. Fix the data foundation for the specific use case – trustworthy, consistent, and available.
2. Build governed integration – controlled, auditable access through APIs you own.
3. Pilot one agent on that foundation, with evaluation and audit built in from day one.
4. Scale only what passes – promote agents that clear your evaluation bar, and retire the ones that do not.

Match the effort to the stakes

Not every process deserves the same rigor. Calibrate:

Use case risk	Governance rigor	Reasonable starting point
Low (internal, reversible)	Light	Fast pilot, learn cheaply
Medium (customer-facing)	Moderate	Human in the loop, full audit trail
High (regulated, financial, core systems)	Maximum	Strict evaluation gates, constrained autonomy

The organizations that will get value from agentic AI in the next year are not the ones with the most agents. They are the ones whose data and integration foundation can actually support the agents they deploy.

Summary: Five Takeaways

The signal from IBM at the Agentic AI Summit 2026, in five lines:

1. IBM brought research, not launches. Four talks on the hard parts of production agents – no announcements at this event. The product news was at Think 2026 in May.
2. The demo is the easy part. Every IBM talk targeted what breaks after the demo: interoperability, evaluation, security, and legacy integration.
3. Agentic AI is a data and integration problem first. An agent inherits every weakness in your data and every gap in your integration – then acts on them at speed.
4. Governance is what makes agents safe to keep. If you cannot audit what an agent did and scope what it can do, it is a liability, not an asset.
5. Sequence matters: data, then integration, then agents. Projects that run this backwards stall at the foundation. Projects that respect it reach production.

The practical next step is not to buy an agent. It is to find out whether your foundation can support one.

FAQ

What is agentic AI in the enterprise?

Agentic AI refers to AI systems that do not just answer questions but take actions – calling tools, moving data, and completing multi-step tasks with limited human input. In an enterprise, the value is autonomy on real work; the risk is an autonomous system acting on untrustworthy data or ungoverned access. The difference between value and risk is your data, integration, and governance foundation.

What is agentic AI architecture?

Agentic AI architecture is the full stack an agent needs to run safely in production, not just the model. It covers interoperability (how agents communicate), evaluation (how you prove reliability), security and permissions (what an agent is allowed to do), and integration (how it connects to your systems). IBM’s research at the summit mapped exactly these layers, which is a useful signal about where the real engineering effort sits.

Why do agentic AI projects fail in production?

They rarely fail because the model is weak. They fail because the data is inconsistent, the systems are not connected through governed APIs, or no one can audit and control what the agent does. A stronger model on a broken foundation just produces wrong actions faster. Fixing the foundation is the project; the agent is the last mile.

What is AI governance for agentic AI, and why does it matter?

AI governance is the operating layer that controls and records agent behavior: scoped permissions, complete audit trails, ongoing evaluation, and clear accountability when something goes wrong. It matters because an agent with broad, unlogged access is a new class of insider risk. Effective governance is enforced by the platform, not by policy documents – if it depends on people following the rules manually, it is not governance.