A vendor event compresses complexity.

A capability is placed on a clean stage. The environment is prepared. The path is known. The demo works.

That is useful evidence.

It is not a production decision.

OutSystems World Tour Las Vegas 2026 is scheduled for October 7. The event is framed around agentic AI, product innovation, and how enterprises build, govern, and scale AI systems. OutSystems is using the theme “Own your agentic future.”

That framing makes the production question more important, not less.

Disclosure: I work for an OutSystems partner and am speaking at the Las Vegas event, in a technical session on evolving a live lending origination system in production. That relationship is relevant to how I evaluate the claims. It is also why I want a harder standard for turning what happens on stage into an operating decision.

The stage removes variables that production puts back

A good demo isolates capability.

It should.

If a vendor wants to show that an agent can complete a workflow, the demonstration should not spend twenty minutes fighting a broken identity provider, cleaning source data, or waiting for a change ticket.

The controlled environment lets the audience see the capability clearly.

The mistake is assuming the controlled environment also proves production readiness.

Production puts the removed variables back into the system:

  • Your identity and permission model.
  • Your data quality and ownership rules.
  • Your systems of record.
  • Your integration surface.
  • Your exception paths.
  • Your security and audit requirements.
  • Your support and change processes.
  • Your users and their incentives.

This is the same distinction behind the pilot is not the product. A pilot can prove possibility. Production proves whether the organization can own the capability over time.

A conference demo is an even narrower test. Its job is to make one capability observable. It is not designed to reproduce your operating environment.

That does not make the demo misleading.

It means the buyer has to restore the missing constraints before making a decision.

Shipping, preview, and roadmap are different evidence classes

Vendor events can flatten time.

Something available today, something available to a limited group, and something planned for later can appear in the same hour with the same production quality slides and the same confidence.

Those states should not carry the same decision weight.

Evidence class What it can tell you What it should not decide by itself
Shipping The capability exists under defined current conditions. Whether those conditions fit your architecture, controls, economics, and operating model.
Preview The vendor has working capability worth testing and learning from. A production dependency that assumes the preview will behave, scale, or commercialize exactly as expected.
Roadmap The vendor is signaling direction and intent. A current architecture, control, or business case that requires the future feature to exist.

This is not about distrusting roadmaps.

Roadmaps matter. Preview access matters. Early capability can change sequencing decisions.

The discipline is to preserve the evidence class.

A roadmap can justify keeping an option open. It should not silently become the missing production control in a plan approved today.

The first useful question in a booth or breakout is therefore simple: What state is this in right now?

The second is more important: What changes when I move it into my environment?

Agentic AI turns capability into an authority question

The phrase “Own your agentic future” is a product statement, but it is also an operating-model statement.

An agent is more consequential when it can do more than produce an answer.

There is a meaningful difference between a system that can:

  1. Read information.
  2. Recommend an action.
  3. Prepare an action for approval.
  4. Execute after a person approves it.
  5. Execute within predefined limits without case-by-case approval.

Each step changes the authority delegated to software.

That means the production question is not only whether the agent can perform the action.

It is whether the organization can define the boundary around that action.

What identity does the agent use?

Which systems can it reach?

Which records can it change?

What values can it commit?

What evidence is retained?

What requires a person?

What happens when the action is wrong?

Who can stop it?

AI governance starts with the decision, not the model, because the consequence of AI depends on what the system is allowed to influence.

The National Institute of Standards and Technology makes governance a cross-cutting function in its AI Risk Management Framework. The framework separates governance, context, measurement, and management because responsible operation is not created by model performance alone.

Agentic systems make that separation easier to see.

Once software receives action authority, governance becomes part of architecture.

Production readiness starts where the demo ends

A useful conference conversation should move from capability into operating conditions.

I would test five surfaces.

Identity and authority

Ask which identity the agent uses, how permissions are scoped, whether access is inherited or explicitly granted, and how quickly authority can be revoked.

The most important permission is often not what the agent can read.

It is what the agent can change.

Data and integration

Ask which data sources, systems, and APIs the capability depends on.

Then ask what happens when the source is incomplete, stale, unavailable, contradictory, or outside the expected schema.

A clean demo path can hide how much of the production problem is really integration and data ownership.

Evidence and observability

Ask what the organization can reconstruct after an action occurs.

Can it see the input, relevant context, tool call, action, approval, output, and downstream result?

If an accountable owner cannot inspect what happened, the system is difficult to govern even when it usually works.

Human control and exceptions

Ask where a person can approve, reject, change, pause, or reverse an action.

Then ask whether that control exists in the operating model or only in the interface.

A button labeled override is not meaningful if the user lacks the authority, context, or time to use it. That distinction is why human in the loop is two designs, not one.

Lifecycle ownership

Ask who owns the capability after deployment.

Models change. Prompts change. Tools change. Data changes. Permissions change. Integrations change. Business rules change.

The system needs an owner who can observe those changes and decide whether the capability should continue operating under the same authority.

What this does not mean

A controlled demo is not a defect. Vendor events are supposed to make capability visible, and OutSystems is explicitly putting governance and secure scaling into the Las Vegas framing. The mistake is asking a demo to prove an operating environment it was never designed to reproduce.

Seven questions to take into every conversation

The goal is not to interrogate a presenter until the demo becomes a design review.

It is to leave with evidence that can survive Monday morning.

For any capability that could become part of a production plan, ask:

  1. Is this shipping, preview, or roadmap? Preserve the evidence class.
  2. What conditions have to be true for this to work in our environment? Surface architecture, licensing, data, and platform dependencies.
  3. What identities, data, and systems can it access? Define the reachable surface.
  4. What actions can it take without a person? Define authority, not just functionality.
  5. What evidence is recorded about each action? Establish observability and auditability.
  6. How can a person pause, override, or reverse the result? Test whether control is practical.
  7. Who owns the system after deployment? Name the person responsible for monitoring, change, and continued acceptability.

A weak answer does not automatically mean the capability is weak.

It may mean the conversation has moved from product demonstration into architecture, governance, or operating design.

That is useful progress.

The buyer now knows which uncertainty still has to be resolved.

The useful takeaway is a better production decision

A conference should not leave an operator with a list of features that looked impressive on stage.

It should improve the next decision.

The useful sequence is simple.

Classify what you saw.

Restore the constraints the demo removed.

Define the authority the system would receive.

Test whether the organization can observe, interrupt, reverse, support, and improve it.

Then decide what deserves a production commitment.

The best result from an agentic AI event is not confidence that the future is possible.

It is clarity about what the organization must own before that future gets write access.

Sources and notes