Can you really build enterprise grade AI agents within a few hours?

A practical guide for executives navigating the agentic shift

It usually starts in a meeting room. A vendor opens their laptop, types a single sentence into a chat box, and watches an agent pull data from three systems, summarise a tenant contract, flag a clause for legal review, and email the result to the asset management team. The whole thing takes ninety seconds. The room goes quiet, then someone says: “How long did that take to build?” The answer “an afternoon” is the moment most enterprise AI strategies are quietly redrawn.

It is a fair question, and at first glance an exciting one. If a working agent can be assembled in an afternoon, why are we still spending eighteen months on every digital transformation? Why are we paying seven figures for software that does less? And, more pressingly, what should we be doing about it?

The honest answer is more nuanced than the demo suggests. Yes, you can absolutely build a working AI agent in a few hours. The tools are now that good. But the gap between a working agent and an enterprise-grade agent is wider than most executives expect, and it is where almost all the real cost, risk, and value reside.

This article is for executives who want to understand what is actually possible today, what is genuinely difficult, and how to move quickly without making the kinds of decisions that look brilliant in May and embarrassing by November. We will look at what agents are, what they are not, where they are working, who is building them, and what it takes to deploy them properly in a regulated enterprise.. By the end you should be able to walk into your next boarding meeting and explain the landscape clearly.

What is an AI agent, really?

Before we go anywhere near deployment, it is worth pausing on what we actually mean by “AI agent”. The phrase has been thoroughly mugged by marketing teams over the past eighteen months, and most executives cannot quite tell whether they are being sold an agent, a chatbot, a workflow tool, or a particularly assertive macro.

The cleanest working definition is this: an AI agent is software that uses a foundation model to understand a goal, plan how to achieve it, take action by calling tools and systems, and adapt based on what it observes. Think of it as a digital graduate. It is competent, it can read instructions, it knows how to ask for help, it can use the tools you give it, and within a defined remit it can make sensible decisions without constant supervision. Like a graduate, it benefits from clear guardrails and a senior colleague reviewing its more consequential work.

Anatomically, every agent draws on five capabilities. A foundation model provides the reasoning engine e.g. Claude ‘Sonnet’, GPT ‘4o’, Gemini ‘3.5 Flash’. Tools give the agent the ability to act: querying a database, sending an email, retrieving a document, executing a calculation. Memory lets it carry context across steps, and in more sophisticated agents across sessions. Orchestration handles planning and routing — deciding what to do next, when to escalate, when to stop. And guardrails define the boundaries: what the agent is allowed to do, what data it can touch, when a human must approve.

Figure 1. The five components of an AI agent.

This anatomy matters because it explains where agents differ from the things they are often confused with. A chatbot has the model and possibly some memory, but no real tools and no orchestration; it talks, it does not act. RPA has tools and orchestration, but no reasoning — it follows a script and breaks the moment reality deviates from it. Traditional machine learning has reasoning of a narrow kind, but no general intelligence, no tool use, and no conversational interface. An agent combines all five components. That is what makes it useful, and that is what makes it new.

One further distinction is worth holding onto: agents are probabilistic, not deterministic. They will sometimes do unexpected things. This is a feature in many use cases, it is what allows them to handle the messy edge cases that defeated previous generations of automation, and a liability in others. Knowing which is which is most of the job.

A taxonomy executives actually need

If “AI agent” covers everything from a daily scheduled report to an autonomous trading system, the term has stopped being useful. In line with how Gartner, Forrester and the major platforms now describe the space, we find it helpful to think along a spectrum of five increasingly autonomous categories.

Figure 2. A working taxonomy of agentic systems.

Scheduled actions sit at the simplest end. These are pieces of automation that run on a timer or a trigger; a daily KPI report, an inbox sweep at 7am, a webhook firing when a deal closes in the CRM. They might use an LLM for one step (summarising a document, drafting an email), but they do not reason about what to do next. Most executives already have several of these; they were called “automation” before the marketing rebrand.

Task agents add a single, scoped LLM-driven task into the picture. A typical example: an agent that reads each inbound email, classifies it by topic and urgency, and routes it to the right team. There is reasoning involved, but only at a single point. The flow around it is deterministic. These are extremely useful, very cheap, and the natural starting point for most organisations.

Automation agents chain together multiple steps within a defined workflow. They are still constrained, the steps are known in advance, but the LLM is making decisions at several points: deciding what tool to call, what data to retrieve, what to do if a check fails. An invoice approval flow that reads a PDF, extracts line items, matches them to purchase orders, and either approves or routes for review is a good example.

Workflow agents are where most of the genuinely exciting enterprise work is happening today. These agents are given an outcome rather than a sequence such as “abstract this 80-page lease and surface anything we should worry about” and decide for themselves how to get there. They will read documents, query systems, ask follow-up questions, and iterate. The workflow is emergent rather than predefined. Reasoning models have made this category dramatically more reliable in the past twelve months.

Multi-agent systems are the frontier. A coordinator agent breaks a goal into sub-tasks and delegates each to a specialist; one for research, one for analysis, one for drafting, one for review. Done well, multi-agent systems handle work that a single agent cannot. Done badly, they create eight times the failure modes for the same outcome. Most enterprises should not start here.

A useful question to ask when a vendor pitches you something is simply: where on this spectrum does it sit? If you are being shown a scheduled action and being charged for a workflow agent, you have just identified the most common form of agentic over-selling in the market. Conversely, if your team is trying to ship a multi-agent system as their first deployment, gently encourage them to start one column to the left.

Why now?

Agents have been promised for years. What changed?

Three things converged. First, foundation models crossed the reliability threshold for tool use. Two years ago, asking a model to call an API and use the result was an exercise in disappointment; today, entry-level Claude, GPT and Gemini models all handle multi-step tool use with a hit rate good enough for production. Second, reasoning models: Claude with extended thinking, OpenAI’s o-series, Gemini’s deeper reasoning modes meaningfully improved performance on the kinds of multi-step, judgement-heavy tasks that real workflows demand. Third, the necessary scaffolding has finally arrived: orchestration frameworks like LangGraph and CrewAI, or alternatively, one of many low-code workflow solutions; evaluation tooling for systematic testing; and the Model Context Protocol (MCP), which gives agents a standardised way to integrate with the dozens of systems an enterprise actually runs on.

The cost curve helped too. The per-token price of frontier intelligence has fallen by an order of magnitude in two years, and the lightweight tier (Claude Haiku, GPT-mini, Gemini Flash) is now cheap enough to run at the scale of every email or every document an enterprise produces.

The result is that we are at a moment that does not come along often: the technology is genuinely capable, the tooling is genuinely usable, and the economics genuinely work. Combined with regulatory frameworks beginning to settle, the EU AI Act is a known quantity rather than a moving target, and Gulf regulators including Saudi Arabia’s SDAIA have published clear positions; 2025–26 is the inflection point where serious enterprises move from experimentation to deployment.

The “few hours” reality check

So can you really build an enterprise-grade agent in a few hours? Yes, and no, and the gap between them is where this article earns its keep.

What you can absolutely build in an afternoon: a working agent that performs a real task. Pick a use case, say, summarising and triaging the contents of a shared inbox. Open Claude Projects, n8n, or your platform of choice. Wire up access to the inbox, write a clear prompt describing the task, give it a knowledge base of past examples, set a schedule. By the end of the afternoon, you will have an agent that does something genuinely useful. Show it to your colleagues. They will be impressed. This is not a trick; it is a measure of how far the underlying tools have come.

What you cannot build in an afternoon is the difference between that demo and something you would actually deploy to two thousand employees across three jurisdictions. To get there, you need access controls so the agent only sees what each user is allowed to see. You need an audit trail that records every decision and every tool call. You need an evaluation framework that tells you whether the agent is right 95% of the time or 70%, and where it tends to go wrong. You need cost controls, because an agent that runs unchecked can burn through six-figure budgets in days. You need human-in-the-loop checkpoints for consequential decisions. You need data residency handled for regions that care (and they all increasingly do). You need a fallback path for when the model is unavailable. You need observability so your operations team can see what is happening. And you need a change-management programme so your staff actually use the thing.

In our experience, the production-hardening effort is typically ten to twenty times the prototype effort. An agent that took a developer three days to build will take a small team three months to make enterprise-grade. This is not a failure of the technology. It is the reality of doing anything responsibly inside a large organisation. The same multiplier applies to a CRM rollout, a data platform, a payments integration. The difference is that the demo of those things is not so good that it makes you forget the rest.

The right way to read the “few hours” claim is this: agentic prototypes are now genuinely cheap. Agentic production is not. The discipline lies in knowing the difference, and in using the cheapness of the first to make better decisions about the second.

How are agents actually built?

There are now three broad ways to build an agent, each with its own audience, ceiling, and trade-offs.

Visual builders

These are platforms where you assemble agents by dragging nodes around a canvas. n8n, Make (formerly Integromat), Zapier’s AI offerings and Microsoft’s Copilot Studio are the leading names. The model sits inside one node, the tools sit in others, and you connect them with lines. Visual builders are spectacular for prototyping and for use cases that look like classic automation with an LLM step bolted on. They are also extraordinary for democratising who can build. A business analyst with no coding experience can have a useful agent running by lunchtime. The ceiling is real but distant, visual builders start to creak when workflows become deeply branching, when state has to be carried across many steps, or when latency and cost need to be tuned precisely. For many internal use cases, that ceiling is fine.

Prompt-led platforms

Claude Projects, ChatGPT Custom GPTs, Gemini Gems, and Microsoft Copilot agents all let you build by writing a careful set of instructions, attaching a knowledge base, and granting access to a curated set of tools. There is no visual canvas, the “building” is a conversation. These platforms are excellent for knowledge agents, research assistants, internal experts, and any use case where the value lives in the quality of the prompt and the documents, rather than the complexity of the workflow. They are also where many executives should start, because they require no engineering involvement at all and produce something genuinely useful in a single sitting.

Code-led frameworks

LangGraph, CrewAI, AutoGen and the LangChain ecosystem give engineering teams full control over orchestration, memory, state, evaluations, and deployment. They are also where Anthropic’s own Agent SDK and the major cloud providers’ agent services live. Code-led builds take longer, require engineers, and are where you want to be when stakes are high, integrations are deep, and the agent is going to handle thousands of requests a day.

The honest position is that most enterprises end up using all three. Visual builders for rapid prototyping and lightweight back-office automation. Prompt-led platforms for knowledge and assistant use cases that empower individual teams. Code-led frameworks for the agents that genuinely matter, the ones in the critical path of a business process or a client interaction. Treating these as competing camps rather than complementary layers is a common mistake, and one that leads to over-engineered solutions to simple problems and under-engineered solutions to complex ones.

The decision is rarely about which tool is best. It is about which tool fits the use case in front of you.

Who can actually build one?

This is the question executives ask most often, usually quietly. The answer is genuinely encouraging: more or less anyone, at least to start.

The entry point to agentic work has been democratised in a way that very few technology shifts have managed. Three years ago, “build an AI system” required data scientists, MLOps engineers, and a budget. Today, a finance manager with a good understanding of their own process can build a working agent in Claude or Copilot Studio without writing a single line of code. We have seen this happen across every function, legal teams building contract review agents, HR teams building onboarding assistants, surveyors building lease abstraction tools, sales teams building proposal generators. The skill that matters is not coding. It is clarity of thought about the task: what does “done” look like, what does the agent need to know, where does a human need to stay in the loop.

This does not mean engineering is irrelevant. It means engineering’s role has shifted. The best operating models we see have IT moving from gatekeeper to enabler, providing the platforms, the guardrails, the access patterns and the evaluation frameworks within which business users can build. Engineering builds the terminal and the runway; the business builds the planes. When something a business user has built becomes critical enough to need hardening, engineering picks it up and productionises it. This is the genuine democratisation people talk about, and it is real.

The implication for executives is significant. You do not need to hire a team of AI engineers to start. You need to give the people closest to the work the tools, the permission, and a small amount of training. The agents that move the needle in our clients’ businesses are almost never the ones imagined in central strategy. They are the ones built by the people who do the work, who know exactly where the friction lives.

Where agentic is taking hold today

Talk about the future of agents tends to sweep past the present, which is a shame because the present is more interesting than people give it credit for. Across our client base, global enterprises, public sector bodies, and the property sector specifically, a small number of patterns are reliably producing value today. They are worth knowing.

Research and synthesis. Agents that read across documents, web sources and internal systems to produce structured summaries. Used heavily for market intelligence, competitor analysis, due diligence, investment screening, and policy review. A good fit because the work is judgement-heavy, repetitive, and tolerant of a human reviewer at the end.

Document processing. Lease abstraction, contract review, invoice processing, claim handling, and KYC. Anywhere unstructured documents need to be turned into structured data plus a flag for the cases worth a human’s time. This is the single most common production deployment in regulated industries, including property.

Customer and employee service. First-line triage that handles the straightforward cases entirely, escalates the rest with full context attached. Done well, these agents do not replace humans, they make sure humans only see the cases that need them.

Internal knowledge. Agents that sit on top of an organisation’s documents, wikis, ticketing systems and email archives, and answer questions in natural language. This is where many enterprises see fastest, easiest value, and where the change management is gentlest because the agent is augmenting rather than replacing.

Code generation. Worth mentioning because it is the use case that has progressed fastest of all. Engineering teams are now routinely 30–40% more productive when using agentic coding tools, and the gap is widening. Even non-engineering executives should care, because it changes the cost curve of every other piece of software you build.

Compliance and assurance. Agents that monitor for breaches, prepare for audits, and surface anomalies. Particularly relevant under tightening regulation in the EU, UK, and Gulf.

What do good use cases have in common? A useful heuristic, which we use with clients: the task is repetitive enough to matter; judgement-heavy enough that traditional automation has failed; well-bounded enough that you can describe success in a sentence; and tolerant of a human-in-the-loop review for the cases that matter. If a candidate use case ticks all four, it is probably worth piloting. If it ticks three, it is worth a conversation. If it ticks one, you are reaching.

Three worked examples

Abstractions are useful only up to a point. To make this concrete, here are three real-world shaped examples drawn from how we are seeing agents deployed across sectors today.

Lease abstraction in commercial property

A mid-sized property firm holds several thousand lease agreements across its managed portfolio. Each lease is forty to ninety pages of dense legal text, sitting as PDFs in a document management system. The asset management team needs to know, on demand, what is in each lease: rent review dates, break clauses, service charge provisions, alienation restrictions, ESG-related obligations, and any unusual terms that might affect valuation or risk.

Historically, this was paralegal work. A new acquisition meant six weeks of manual abstraction before the asset could be properly modelled. Today, a workflow agent can abstract the same lease in fifteen minutes, structured into the firm’s preferred schema, with flags on anything unusual that a chartered surveyor should review. The build time for the first version was around a week in a visual builder. Hardening it for production, adding audit trails, evaluation suites against a labelled corpus of leases, integration with the document management system and the asset register, and a careful escalation path for ambiguous clauses took four months. The payback was inside a year, and the work that was previously a bottleneck on every transaction is no longer a bottleneck on anything.

Internal IT helpdesk for a multinational

A global services firm with fifteen thousand staff was running an internal helpdesk that was buckling under the load. Most tickets were variations of a few dozen patterns: password resets, software access requests, VPN issues, expense system queries. The team estimated that 60% of tickets could be resolved without human intervention if the right context and tools were available.

They built a task agent, a single, scoped LLM step embedded in the existing ticketing platform, that read each inbound ticket, attempted to resolve it directly using a small set of pre-approved tools (the identity system, the software catalogue, the expenses API), and either closed the ticket or routed it to a human with a draft response and full context. Build time for the initial prototype: two days. Time to production: three months, mostly spent on access controls, audit logging, and tuning the escalation thresholds so that nothing important slipped through. Result: ticket resolution time fell by 70%, the first-line team was redeployed to more interesting work, and the agent now handles around half of all inbound volume.

Vision 2030-aligned investment research in the Kingdom of Saudi Arabia

A sovereign-linked investment vehicle wanted to systematically screen opportunities against Vision 2030 priorities, sectors flagged for diversification, regional development objectives, and ESG criteria specific to the Saudi context. The volume of potential targets, briefing papers and regulatory filings was such that no human team could review them comprehensively.

A multi-agent system was the right answer here. A research agent pulled and structured information about each opportunity from public filings, news, and licensed databases. An analysis agent assessed alignment against the Vision 2030 framework. A risk agent surfaced regulatory and reputational concerns. A drafting agent produced a structured briefing for the investment committee. Build time for the prototype: about three weeks, because the multi-agent coordination required real engineering. Hardening for production: six months, with particular attention to data residency (everything had to run inside the Kingdom), Arabic-language handling, and a rigorous evaluation framework against historical decisions. The system now processes more opportunities than the previous human team did, with the committee seeing more comprehensive briefings and reviewing only the genuinely material decisions.

What is striking across all three is the ratio. In each case, the prototype was days to weeks. The production deployment was months. And in each case, the value would not have been captured without doing both. The prototype proves it works. The production deployment captures the value.

Choosing your foundation model

Sooner or later, an executive sponsoring an agent programme will be asked: which model should we use? The honest answer is “it depends, and probably more than one”, but that is not useful without unpacking. Here is a balanced view of the major options in 2026.

Frontier closed model services

Claude (Anthropic). Generally regarded as the strongest for logical reasoning, particularly involving tool use, long context, complex reasoning, and careful judgement. Extended thinking modes give Claude an edge on complex tasks. Excellent at following nuanced instructions, which matters when guardrails are part of the design. Strong enterprise posture, with clear positions on training data, IP indemnification, and a maturing set of enterprise controls. Trade-offs: per-token costs are at the higher end of the frontier tier, and availability outside the major cloud regions has historically lagged the others.

GPT (OpenAI). Home of the most widely deployed and best-known frontier models, with the deepest ecosystem of tooling, integrations and ready-built agents. The o-series reasoning models are competitive on the hardest tasks. Strong on code, very strong on developer ergonomics. Trade-offs: model behaviour has shifted noticeably across releases, which can be uncomfortable for production systems where consistency matters. Enterprise pricing and posture have matured, though some organisations remain cautious for sensitivity reasons. GPT-generated content is often considered relatively eloquent compared to Claude-generated content.

Gemini (Google). Excellent on multimodal tasks (the strongest of the three for native handling of images, video and audio), and integrated tightly into the Google Workspace and Google Cloud ecosystems. Gemini Flash is genuinely cheap at scale, which makes it the default choice for high-volume, lower-complexity workloads. Trade-offs: the reasoning gap on complex agentic tasks has narrowed but not closed against Claude and the o-series.

Open-weight models

Llama (Meta). The most widely deployed open-weight family, with strong ecosystem support and competitive performance at the larger sizes. The natural choice when self-hosting is required for data residency, cost predictability at very high volumes, or organisational policy. Trade-offs: licence terms are workable but not as permissive as truly open licences; performance on the hardest reasoning tasks still trails the frontier.

Mistral. European-headquartered, with strong models across multiple sizes and an enterprise-friendly licensing position. A natural fit for European clients concerned with sovereignty, and increasingly capable at the larger sizes. Mistral’s smaller models are particularly strong as the workhorse layer in a routed deployment. Trade-offs: more limited ecosystem than Llama, and reasoning capability still some distance behind the frontier closed models.

Qwen (Alibaba). The Chinese-headquartered family that has improved fastest over the past year. Strong multilingual handling, particularly Chinese and Arabic, and competitive performance at the larger sizes. Of growing relevance to organisations operating across Asia and the Gulf. Trade-offs: organisational considerations vary by jurisdiction; some enterprises will not consider Chinese-origin models regardless of capability.

Artefact’s decision framework

In practice, we encourage clients to think along two axes: how complex is the task, and how sensitive is the data?

Figure 3. A two-axis decision framework for choosing a foundation model.

For complex tasks on non-sensitive data, the frontier closed models from Claude, GPT, or Gemini via a managed API are almost always the right starting point. The reasoning quality matters more than the cost or the deployment overhead.

For complex tasks on sensitive data; patient records, financial transactions, sovereign data, a self-hosted open-weight model is increasingly viable, particularly with Llama at the larger sizes. Performance is sufficient for most enterprise tasks; data residency and control are non-negotiable.

For simple tasks on non-sensitive data, the lightweight model tier; Claude Haiku, GPT-mini, Gemini Flash handles enormous volumes at marginal cost. This is where the per-email, per-document, per-transaction agents live.

For simple tasks on sensitive data, a small self-hosted model; Mistral small, Qwen 2.5, or a fine-tuned Llama is usually the most cost-effective answer.

The task is undemanding enough that the smaller model is sufficient, and self-hosting handles the sensitivity.

The most sophisticated deployments now route between these quadrants dynamically. A user request comes in, a small routing model classifies it, and the request is sent to the cheapest model capable of handling it. This is how the economics actually work at scale and how enterprises avoid either overpaying for routine tasks or under-serving the difficult ones.

One further prompt: do not lock yourself in. Architect your agentic platform so that the model is replaceable. The leaders six months from now may not be the leaders today; the model layer should be a swappable component, not a structural commitment. If a vendor’s proposal makes this difficult, ask why.

The blockers, technical and organisational

This is the section that, if you are reading this article seriously, you should probably read twice. The blockers to enterprise-grade agentic deployment are well known to anyone who has actually done it, and they split roughly equally between the technical and the organisational. In our experience the organisational side is the harder half, and the side that most leadership teams under-invest in.

Figure 4. The blockers that most often stall agentic programmes.

Technical blockers

Data quality. The single most common reason agentic pilots fail to scale. Agents are only as good as the data they reach. Inconsistent formats, duplicated records, missing fields, and orphaned data sources defeat them quickly. A data audit before, not after, a pilot is the cheapest improvement most organisations can make.

Unstructured data sprawl. For most enterprises, 70–80% of the data that matters lives in PDFs, emails, scans, shared drives and intranet sites. Agents can handle this, but only with the right retrieval architecture and a willingness to invest in extracting, indexing and governing it.

Weak data governance. Lineage, access controls, residency, and retention policies all become critical when an agent can read and act across your data estate. Most enterprises discover their governance is weaker than they thought the first time an agent does something unexpected.

Brittle system integrations. Legacy ERPs, bespoke APIs, and systems that were never designed to be queried programmatically all create friction. The Model Context Protocol is meaningfully helping here, but a long tail of legacy still bites.

No evals or observability. The single biggest red flag in a vendor pitch is the absence of an evaluation framework. If you cannot measure whether the agent is right, you cannot deploy it. We have seen sophisticated organisations skip this and live to regret it.

Cost and latency surprises. Token spend can compound quickly. Latency on long-context, reasoning-heavy agents can creep into territory that breaks user experience. Both need to be monitored from day one, not discovered in month four.

Organisational blockers

Unclear ownership. Agentic work sits awkwardly between IT, data, and the business. Without a clearly designated owner, and a sponsor with the political authority to break ties, programmes get stuck in approval limbo or fragment into shadow projects.

Misaligned incentives. People are rewarded for the work they currently do. If an agent threatens that work, the people best placed to make the agent useful are the same people most likely to obstruct it. Naming this honestly is half the solution.

Operating model mismatch. Most enterprises are organised for projects with defined endpoints. Agents are products that need ongoing tuning, evaluation, and improvement. Trying to deliver agentic work through a project operating model produces brittle deployments that decay.

Change-management debt. The hardest part of agent deployment is not building the agent. It is redesigning the work around it. Most organisations have not invested in the change muscle needed to do this well.

Fear of displacement. Adoption stalls when staff fear the agent is there to replace them. The strongest deployments we see are explicit and credible about this: the agent handles the dull bits so people can focus on the parts of the job that need their judgement. Saying it is not enough; behaviour has to back it up.

Low evals literacy. Executives who cannot meaningfully interrogate whether an agent is working are easily sold on demos that do not generalise. Building a shared vocabulary; accuracy, precision, recall, hallucination rate, escalation rate, cost per resolution, is now part of the executive job description for anyone overseeing agentic work.

If we had to pick the two blockers worth most attention from senior leadership: data governance on the technical side, and operating model on the organisational side. They are the ones that, if left unattended, will quietly limit the value you can capture no matter how good the models become.

Anatomy of an enterprise-grade deployment

A useful question to ask of any agentic system before it goes near production is: what would have to be true for me to be comfortable when this fails publicly? Because at scale, agents will fail publicly. The discipline is making sure that when they do, you can see it, contain it, and recover quickly.

Enterprise-grade deployment requires a small set of non-negotiables. None of them are exciting on their own; together they are the difference between something you would happily explain to a regulator and something you would prefer not to.

Identity and access management. Every agent action should run under an identity, with permissions inherited from the user it is acting on behalf of. Agents that operate with broad service-account privileges are an outage and an audit finding waiting to happen.

Audit logging. Every decision, every tool call, every escalation should be logged, immutable, and queryable. Not optional. Regulators in financial services, healthcare, and increasingly other regulated sectors will ask. You want the answer to be “yes, here”.

Evaluation framework. A labelled test set that the agent is evaluated against before every release, with clear thresholds for what passes. This is the single highest-value investment most teams under-make. If your team cannot show you their evals, they have not built an enterprise-grade agent.

Observability. Real-time visibility into how the agent is performing in production: success rate, latency, cost per request, escalation rate, drift over time. The same metrics you would expect for any production service, instrumented at the agent level.

Cost controls. Per-user, per-agent, and per-tenant spend caps. Alerts. Automatic throttling on runaway loops. Token spend without controls is the agentic equivalent of a memory leak.

Human-in-the-loop checkpoints. Decisions of consequence should pause for human review, with the agent presenting context and a recommendation. Where the threshold sits depends on the use case; that the threshold exists at all is non-negotiable.

Data governance and residency. Clear policies on what data the agent can read, write, retain and transfer across borders. Particularly material if you operate across the EU, UK, Gulf, and other regimes with their own positions.

Fallback behaviour. What happens when the model is unavailable, the response is unparseable, or the tool call fails. Production agents need graceful degradation, not silent failure or unexpected behaviour.

Scalability patterns. The architecture should handle 100x the launch volume without re-platforming. Routing between models, caching, async processing, queue-based execution: standard distributed-systems hygiene applied to a new substrate.

None of these are exotic. All of them are routinely missed in agentic systems that have been built quickly and never properly hardened. The reason the gap between prototype and production is so wide is that this list is the gap.

The deployment journey playbook

Across the agentic deployments we have run with clients over the past two years, a clear five-stage pattern has emerged. Naming it openly helps executives plan budgets, expectations, and the right people in the room at the right time.

Figure 5. The five stages of an agentic deployment.

Stage 1: Discover. Identify candidate use cases, size their value, audit the data they would need, and pick one to two for a first pilot. The discipline at this stage is saying no, most candidate use cases are not yet ready, and starting in the wrong place is the most common reason programmes lose momentum. The room: business sponsor, operators who do the work, a data lead.

Stage 2: Prototype. Build a working agent for the chosen use case, end-to-end, in days to weeks. Visual builders or prompt-led platforms are usually the right tools at this stage. The goal is to prove the use case works in principle, not to build the production system. The room: a small build team, business users for feedback, engineering to advise on the path to production.

Stage 3: Harden. The longest and most under-budgeted stage. Build the evaluation suite, add access controls, instrument observability, decide on the human-in-the-loop checkpoints, run pre-production testing. Most enterprises stall here, because the work is unglamorous and the prototype already looks impressive. The room: engineering, security, risk and compliance, change management.

Stage 4: Deploy. Roll out to pilot users, watch the metrics carefully, iterate based on real usage. Plan for the change management; train the users, set expectations, build the feedback loop. Most deployments need three to six weeks of careful monitoring before broader rollout. The room: operations, change and HR, the original business sponsor.

Stage 5: Scale. Extend the agent to broader populations, capture reusable patterns and components, build the centre of excellence that will support the second, third and fourth use cases. This is also where the operating model question becomes serious: how does the organisation actually run an estate of agents over time? The room: the executive sponsor, the emerging AI leadership, the operating model owner.

Most enterprises today have several pilots in stage 2 and very few systems in stages 4 or 5. The competitive advantage in the next two years will accrue disproportionately to the organisations that learn to get cleanly from stage 3 to stage 5.

Near- to mid-term outlook

What does the agentic landscape look like in 12 to 36 months? Four shifts are already visible and worth planning around.

Multi-agent systems become standard for complex work. Today, multi-agent is the frontier. By 2027, it will be the default architecture for any non-trivial agentic workflow. The orchestration tooling is maturing rapidly, and the cost of running multiple specialised agents is now low enough that the engineering simplicity of “one big agent” is no longer cost-justified. Enterprises that have invested in evaluation frameworks and observability will scale into this comfortably. Those that have not will struggle.

Agent marketplaces and reusable components. The current state; every enterprise building every agent from scratch is transitional. We expect a meaningful shift towards marketplaces of pre-built agents and reusable components, both vendor-supplied and within enterprises. The internal equivalent of a private app store is already emerging in larger clients. For executives, this changes the build-versus-buy question, which will look more like build-versus-compose by 2027.

Agentic process mining. Process mining vendors are rapidly adding agentic capabilities, and AI-native process discovery is emerging from the other direction. The combination agents that can map your processes, identify opportunities, and then implement the resulting workflows will become a more meaningful category. Treat current vendor pitches in this space with care; the technology is moving fast and lock-in risk is real.

Regulation tightens. The EU AI Act’s high-risk system requirements come into force progressively through 2026 and 2027. The UK is taking a more sectoral approach, but financial services, healthcare and critical infrastructure are all in scope. Saudi Arabia’s SDAIA and the UAE’s AI office have published frameworks that will mature into binding requirements. South Korea’s AI Basic Act came into force in January 2026. In the US there is a changing patchwork of state legislation. And sectors are responding with updated guidance: RICS is updating its guidance for the property sector, Singapore’s MAS has published principles and methodologies specifically for AI in finance, insurers are now asking law and accounting firms at renewal whether they have AI usage policies in place. The compliance burden is increasing, but it is also becoming clear what compliance looks like. Plan for it; do not be surprised by it.

The single most important strategic point for executives to internalise: the foundation models will continue to commoditise. The competitive advantage will not sit there. It will sit in the proprietary data you have access to, the workflows you have re-engineered around agentic capability, and the evaluation infrastructure you have built that lets you ship improvements faster than your competitors. Organisations investing in those three things now will compound advantage; organisations betting on a particular model being the winner will not.

The temptation to wait until things settle is understandable. It is also expensive. The cost of starting now is mostly the cost of mistakes; the cost of waiting two years is the cost of being structurally behind competitors who learned by doing.

A measured answer to the headline

So, returning to the headline: can you really build an enterprise-grade AI agent within a few hours?

You can build an agent in a few hours. You can build something useful in a few days. You can build something genuinely good in a few weeks. But enterprise-grade, the kind of system you would happily put in front of your most important clients, your regulators, and your board takes months of careful work even with the best tools. And that gap is not closing as quickly as the headlines suggest. If anything, it is widening, as the bar for what “enterprise-grade” means rises in parallel with the capabilities of the underlying models.

The good news is that the cost of finding out has dropped to almost nothing. Three things any executive can do next week, without budget approval, without a steering committee, and without committing to anything strategic.

First, pick one repetitive, judgement-heavy, well-bounded task in your own work. Build a basic agent for it in Claude, ChatGPT, Gemini or Copilot Studio. Use it for a fortnight. You will learn more in those two weeks than from any number of slide decks.

Second, audit one process in your business against the four-part heuristic from earlier: repetitive, judgement-heavy, bounded, tolerant of human review. The candidates that emerge are where your real opportunities sit.

Third, ask your team a single question: what is our eval framework? If they cannot answer cleanly, that is your starting point.

The companies that get this right in the next eighteen months will not be the ones that built the cleverest demos. They will be the ones who learned, quickly and honestly, to close the gap between a working agent and an agent that actually works.

Case Studies

A visual builder solution for CRE analysts

Artefact helped a CRE gain strategic self-sufficiency in Task Agent development via training, mentoring and pair programming sessions for their in-house analyst team – while leading delivery of three working Task Agents. The agentic architecture was constrained to Claude (foundation model service) and Power Automate (orchestration, memory, tools and guardrails), so that the agents could consist broadly in the same tool ecosystem the in-house team were accustomed to and capable of maintaining alongside their existing tech.

In this way the agents were credited with some attributes of a production service but not others. Including audit logging, observability and scalability. Nevertheless, in a short time the CRE took on concise but effective data governance and residency, human in the loop checkpoints and identify and access management together with rudimentary evaluation pipelines and administration procedures – setting them on course to realise meaningful efficiency gains.

Workflow Agent innovation for a global PE

Artefact developed a prototype Workflow Agent implemented in Claude ‘Skills’ into a highly performant Claude ‘Connector’, representing use of MCP to transition from defining an AI task exclusively in natural language to defining the task as a composition of high performance AI tools. The key distinction making the solution a Workflow Agent and not merely a Task Agent is application of an primary LLM to manage the sequence of tool calls – in addition to invocation of secondary LLMs to carry out tool operations.

Introducing the Claude Connector pattern alongside an existing Azure stack created a novel requirement for support of network ingress and data access. In organisations where common utilities such as these are successfully managed as shared services, we see the time to deployment of new production services reducing up to threefold with each new roll-out.

Chris de Gruben is a Senior Director at Artefact, where he leads the property sector across the UK and EU. He works extensively with public and private sector clients across the UK, Europe and the Gulf.

Oliver Richardson is a Senior Machine Learning Manager at Artefact, who has supported organisations across finance, commerce and government deploy state of the art AI/ML products for over 20 years.

Artefact partners with enterprises to design, build and operate AI systems at scale, from first pilot to enterprise-grade deployment. If the gap between prototype and production is something you are navigating today, we would be glad to compare notes.