From Experiment to an Agent You Can Put to Work

Silvan Maeder, co-founder and CTO of cubesys, on what it really takes to move an AI agent out of the demo and into the business, and why the hardest part is not the technology.

Anyone can build an impressive AI demo in an afternoon. Putting an agent into real work, where people rely on what it produces and someone is accountable when it gets something wrong, is a different job altogether. We sat down with Silvan Maeder, co-founder and chief technology officer (CTO) of cubesys, to talk through how AIForge, our agent-building practice, gets from one to the other. Here is what he told us.

A Demo Shows Capability. Production Needs a Home

"A demo can show some capability," Silvan says. "A production agent is built into the business process and has defined ownership, governance, escalation paths, success measures and ongoing monitoring." That list is the gap. A demo answers one question: can it do this? A production agent has to answer several more. Who owns it? Where does it sit in the process? What happens when it is unsure? And how will anyone know it is still doing its job next quarter?

Start With the Work, Not the Technology

AIForge is deliberately front-loaded on readiness. Before anyone discusses prompts, models or platforms, we map the process: who does the work, what decisions get made and which systems are involved. Then we define what good looks like and decide what role an agent should play, whether that is assisting a person, automating a step or simply providing intelligence. Why so much effort before the build? "Agents inherit process flaws," Silvan says. "If a process is unclear, undocumented or inconsistent, the agent simply amplifies the chaos we already have." In our experience, the agent projects that succeed are the ones that begin with workflow mapping and process improvement. Readiness first, then fit, then build.

Inside an AI Contract

Before we build an agent, we write its AI Contract. Silvan describes it as the employment contract for your agent. It sets out:

• the business outcome the agent is there to deliver
• its scope of responsibility
• escalation paths and the points where a person must approve
• how success will be measured
• the data sources it can use
• the governance requirements it must meet
• who owns it.

Just as importantly, it sets out what the agent must never do on its own. "The purpose is really simple," Silvan says. "Everybody should understand exactly what the agent is allowed to do, what it is expected to achieve and where human accountability remains." The contract is signed off with the customer stakeholders who will own the agent, and our consultants build to it. Every field is there because it answers a question that would otherwise stall the agent later, usually at the moment somebody senior asks who is responsible for it.

Governance Shapes the Design, Not Just the Paperwork

Governance is often treated as something you add once the agent works. Silvan sees it the other way around. "It directly influences the architecture," he says. Decisions made in the contract change how the agent is built. High-risk actions can require a human approval step. Certain outputs may need validating before they are released. Sensitive data may sit behind retrieval restrictions. Audit logs may be mandatory. "Governance decisions determine what the agent can and cannot do, and what evidence needs to be kept," Silvan says. "Good governance shapes the design. It is not an afterthought." Because those decisions are settled before the build starts, they are designed in rather than bolted on.

How We Know It Works, and What Happens When It Does Not

We test agents against business outcomes, not just technical accuracy. Is it reducing effort? Is it reducing delays? Is it improving consistency? Does it follow the agreed process? And the question that matters most: would the business trust the result? "Failure isn't necessarily a wrong answer," Silvan says. "Failure is when the agent produces an outcome that damages trust, creates rework or breaks compliance boundaries." Each agent is validated against its contract on exactly those terms. When an agent cannot complete a task, it should fail safely. If confidence is low, information is missing or an approval is required, it escalates. "Knowing when the agent has to stop is one of the most important design principles," Silvan says. "In many cases, the best outcome an agent can produce is a well-structured handover to a human rather than a forced answer."

What Building for Ourselves Taught Us

cubesys is the first customer of AIForge. Many of our internal agents exist because we had a real operational problem to solve in documentation, governance, project delivery or knowledge management. Using them ourselves first surfaced the edge cases, the governance issues and the adoption challenges before any customer met them. One lesson was humbling. "Conversation isn't always the best interface, and an agent isn't always the answer," Silvan says. "Sometimes a workflow, a form or a dashboard is a better solution." That made the methodology stronger. We stopped trying to force AI into every problem and started choosing the right tool for each one, and there are plenty of places where an agent is exactly the right tool. It also changed Silvan's own thinking. "I used to think the hardest part would be the technology, and it wasn't," he says. "The hardest part is organisational clarity." A successful agent needs defined processes, documented decisions, quality information and clear ownership. The technical build is often the easier part.

What to Ask Any Vendor Offering to Build You an Agent

If someone offers to build you an agent, Silvan suggests starting with questions that do not begin with the technology:

• What business problem are we solving, and how will success be measured?
• What governance controls exist, and how is risk identified and managed?
• Will the agent fail safely when it is unsure?
• What happens once it goes live? How is it managed, what is logged and can it be turned off safely? "If the conversation is focused on prompts and models, I think that would be a warning sign," he says. "The important discussion is about the process, the risk and the business value."
  

The Organisations That Will Win

"Organisations don't need agents for the agents' sake," Silvan says. "They need a repeatable way to identify opportunities, govern risk, measure value and continuously improve." That is why AIForge is more than a delivery methodology. It is a framework for adopting AI responsibly, and it is why we have certified our own AI management system to ISO/IEC 42001, the international standard for managing AI. He closes on the bigger picture. "The future won't be won by organisations with the most agents. It will be won by the organisations that integrate agents into well-designed systems, where people, process and technology work together." What would you like an AI agent to do for your business? Let us explore it together