Three Frameworks That Make Agentic AI Actually Usable in the Enterprise

Andreas Kurz, Global Head of Digital Transformation at Alfagomma and adjunct faculty at NUS Business School, presented at apidays Singapore 2026.

Most organisations currently pouring money into agentic AI are building their almighty agent — one system to handle everything. Andreas Kurz has watched this play out repeatedly, and he has a simple question for every executive who arrives with that plan: do you think this will work?

It is a rhetorical question. The answer is always no.

At apidays Singapore 2026, Kurz presented a tightly argued session on why enterprise agentic AI keeps failing to deliver, and what three specific frameworks — developed at Alfagomma and refined through executive education at the National University of Singapore — actually fix the problem.

Why the "almighty agent" fails

Before getting to the frameworks, Kurz set the context for why structured thinking about agents matters at all. Executives and investors are throwing money at AI without requiring a return on investment. Social feeds generate constant FOMO. Vendors are happy to sell an agenda.

Cutting through that noise, Kurz argued, requires frameworks — not because frameworks are fashionable, but because fast-evolving technology has always rewarded practitioners who build structured approaches to navigate it.

His starting point is a definition. An AI agent has four characteristics:

• An objective — the task it must accomplish, given via a prompt
• Capabilities — the model that powers it, selected for the complexity of the task
• Context — information not in the model's training data (proprietary documents, internal records)
• Tools — access to systems, servers, and APIs through which the agent takes action

That last element is worth underscoring at an API conference: the primary way agents interact with enterprise technology is through APIs. The API layer is not incidental to agentic AI. It is the mechanism of agency.

Framework 1: Human-to-AI Agent

The first framework is, in Kurz's view, the most important — and the one he always teaches first.

The human-to-AI agent framework gives leaders a structured method for identifying where agentic AI can replace or augment existing processes. Its insight is deceptively simple: an AI agent and a human employee are structurally identical in terms of what they need to function.

When executives see this laid out, the response is consistently the same: "I got it." The framework demystifies what had seemed opaque and gives leaders a practical transfer method — take an existing process, map it to these four elements, and you have the blueprint for an agent.

Alfagomma tested this directly on one of its largest operational problems: document automation. Across 26 global entities, the company generates roughly 250 documents per day per entity. Each document required approximately two minutes of manual handling — scanning, digitising, uploading to systems. Multiplied across the organisation, the accumulated manual effort was enormous.

Applying the human-to-AI agent framework, the team translated this process into an agentic solution by mapping each of the four elements: what objective does the agent need, what capabilities does the task require, what context does it need access to, and which APIs does it need to touch. The operational impact will be covered below.

Framework 2: One Agent, One Tool

After executives work through the first framework, the inevitable next move is to build one agent that does all of it. Kurz has learned to anticipate this.

The one agent, one tool framework addresses the structural reason that approach fails. It draws on the same organisational logic that humans already understand intuitively: no high-performing organisation runs on a single generalist doing everything. Complex work is divided across specialists, with someone responsible for triaging and routing.

The framework maps this directly to agent architecture:

• Manager agent — handles triage, decides what to do next, routes tasks to the appropriate workers
• Worker agents — each responsible for one specific step in the process
• One agent, one tool — each worker agent has access to a single API endpoint

The rule is concrete and deliberate. If a process requires access to five different APIs, there are five agents. A get-customer agent, a post-customer agent, an edit-customer agent — not one agent with access to all three. This constraint achieves two things: it dramatically reduces the scope of each individual agent, and it slashes the prompt engineering overhead required to make each one reliable. A smaller, focused agent succeeds on the first attempt far more often than a complex, multi-purpose one.

The result at Alfagomma: a 60% reduction in token usage when the team moved from a single master agent architecture to the one-agent-one-tool structure. Two factors drove this. Prompts became shorter. And agents stopped needing multiple iterations to complete tasks — the success rate on first attempt increased substantially.

Framework 3: The Three-Layer Agentic Architecture

The third framework is the most technical, and Kurz reserves it for postgraduate students rather than executive audiences. But its operational impact is significant enough to include here.

The challenge it solves: once an organisation has many agents built on the first two frameworks, how does it run them efficiently, consistently, and at scale without building each one from scratch?

The three-layer architecture is Alfagomma's answer — a standardised boilerplate that is simple to understand, robust to operate, and built with security and auditability in mind.

Layer 1: The Hook Layer

This layer defines how agents are invoked. The key insight here challenges a common assumption: agents do not have to be triggered by a user typing into a chat interface.

Hooks can include an email arriving, a new Teams message, a scheduled trigger (every five hours, every morning at 5am), a customer action on a website generating a webhook, or a direct API call. Changing how practitioners think about invocation unlocks a much wider range of use cases and removes the dependency on human-initiated prompts.

Layer 2: The Queue Layer

Every invocation is captured in a queue before any agent acts on it. This ensures that every trigger is stored, replicable, and auditable.

The architecture uses two types of queues. The manager queue receives all incoming messages — no agent skips this level, a design choice that mirrors organisational hierarchy for a reason. The manager processes the message, triages it, and routes relevant tasks to worker queues. Each worker agent has its own dedicated queue: a separate inbox, like the individual mailboxes of employees within a team.

Layer 3: The Agent Runtime

This is where execution happens, and it is fully standardised. When an agent is triggered from the queue:

1. A default agent is spun up
2. Based on the agent type, it receives the objective (system prompt), the appropriate model, the required context, and the relevant tool access
3. It executes the task and determines the next action

Kurz illustrated this with a concrete example: a new customer record is created in the company's CRM. A webhook fires, sending the event to the manager queue. The manager agent is invoked, retrieves the message, checks the vector database of existing customers to identify potential duplicates, then determines the next action — in this case, invoking a worker agent to verify the address. That worker agent receives the standard prompt plus the specific address, runs its model, and executes its task. Each step is logged, tracked, and auditable.

The architecture is designed so that adding a new agent is fast. The process: identify the hook, define the prompts, spin it up.

Measured results

The frameworks are not theoretical. Across Alfagomma's implementations, Kurz reported three measurable outcomes:

Document automation pipeline: a positive impact of two FTEs per participating entity — not through redundancies, but through eliminating manual work that people did not want to do, freeing capacity for higher-value tasks.

Token efficiency: a 60% reduction in token usage by moving from a monolithic master agent to the one-agent-one-tool structure. Smaller prompts and higher first-attempt success rates both contribute.

Time to ship: new agents now go from requirement to deployment in days, not months. Internal customers come with a problem, the team refines the prompts, identifies the hook, and the agent goes live.

The practical takeaway

Kurz closed with an observation that is easy to overlook in the current enthusiasm for agentic AI: the technology itself is not the constraint. Context window limits and agent complexity are well-understood problems. What holds organisations back is the absence of a structured approach for translating operational reality into a form that agents can handle reliably.

The three frameworks — human-to-AI agent, one agent, one tool, and the three-layer architecture — offer that structure. They do not require exotic infrastructure or frontier models. They require clarity about what agents are, how organisations actually work, and how to build systems that are auditable by design.

For technology leaders navigating the current noise around agentic AI, that kind of rigour is rarer than it should be.

Andreas Kurz presented "From Theory to the Boardroom: Agentic AI Frameworks for Real Operational Impact" at apidays Singapore 2026. He is Global Head of Digital Transformation at Alfagomma and adjunct faculty at NUS Business School.

Connect with Andreas: LinkedIn