Agentic AI Trends 2027

Yuri Musienko  

  Read: 14 min Last updated on August 27, 2026

Yuri - CBDO Merehead, 10+ years of experience in crypto development and business design. Developed 20+ crypto exchanges, 10+ DeFi/P2P platforms, 3 tokenization projects. Read more

Gartner expects more than 40% of agentic AI projects to be cancelled by the end of 2027. The reasons it lists are not model quality: rising costs, unclear business value, and inadequate risk controls. That prediction is worth taking seriously, because it describes a failure of engineering discipline rather than a failure of the technology.

We build fintech and Web3 systems, and we have shipped multi-agent architectures into client environments. This article covers what actually changes between now and 2027, where the real cost sits, and which parts of the stack we would build first — with the numbers from our own estimates and production incidents attached. If you want broader context on adoption rates before reading further, our compilation of AI market growth statistics 2026 covers the enterprise deployment curve in more detail.

What "Agentic" Actually Means in 2027

Agentic AI vs Generative AI

The distinction matters most where money moves. A model that suggests is a tool. A system that acts is infrastructure, and you have to engineer it accordingly.

Agent, Workflow, or Assistant — a Decision Matrix

Not every multi-step automation needs an agent. A workflow is deterministic: condition A holds, so B runs, then C. An assistant helps a human retrieve information or draft an output, and the human takes the final action. An agent earns its place only when the system has to make bounded decisions, select tools, or determine the next step from changing conditions.

Many products marketed as AI agents are workflows with an LLM in the middle. If a classifier and a rule set solve reconciliation reliably, adding autonomous planning adds cost and risk without adding capability. Use the least autonomous architecture that reliably delivers the business outcome.

The same discipline applies to the components underneath. Teams routinely rebuild infrastructure that already exists in mature form, and the reasoning we use for that call is identical to the one in our analysis of whether to build or buy matching engine components: build only where the differentiation is real and the failure cost is yours to own.

Trend 1 — Multi-Agent Systems Replace Single-Task Bots

The next stage of agentic architecture is not one superagent with access to every system. It is a governed network of specialists. Gartner expects roughly a third of agentic implementations to combine agents with different skills by 2027, and expects most multi-agent systems to lean on narrow specialists rather than generalists.

For fintech the shape is obvious. A transaction can move through a risk agent that scores behavioral and transactional signals, a KYC/AML agent that checks customer and regulatory context, a reconciliation agent that compares ledger records against the payment provider and the chain, and an orchestrator that decides whether the combined verdict justifies the next action.

We have built exactly this pattern for a trading signal system, and the engineering lesson was narrower than we expected: specialization only pays off if the synthesizer weights its inputs correctly. We ran six specialist agents — technical, sentiment, on-chain, news, macro, and a synthesizer. Each one returned a structured confidence score with an explicit reasoning chain, not free-form text. Critically, we calculated the technical indicators in Python with pandas-ta and handed the agent finished numbers. The LLM interprets values; it never computes them. That single decision removed the most expensive class of hallucination in the system.

The synthesizer does not average the agents. It weights them dynamically against their demonstrated accuracy in the current market regime, which a separate classifier determines. One agent scored 67% accuracy in trending markets and 41% in ranging ones — so the moment the regime classifier flags a sideways market, that agent's influence drops automatically. Without that mechanism, a multi-agent system is just a more expensive way to be confidently wrong.

Specialization also changes what you can honestly promise. A single deterministic bot has a strategy; a multi-agent system has a portfolio of opinions and a mechanism for resolving them, which is a materially different engineering problem from the one described in most guides on how to create a crypto trading bot.

Every handoff between agents needs explicit schemas, confidence thresholds, context boundaries, and error-handling policy. Without them, context drift becomes systemic: agent A misreads a transaction, agent B trusts that reading, agent C acts on it, and the original error becomes nearly impossible to isolate. Treat inter-agent communication as service-to-service traffic, not as a chat transcript — because that is what it is.

Trend 2 — Agentic Payments Became Real Settlement Infrastructure

The largest architectural shift for fintech and crypto teams is happening below the model layer, and it moved faster than most 2025 forecasts predicted.

Traditional payment infrastructure assumes a human. Someone creates an account, authenticates, picks a payment method, accepts terms, enters card details, and confirms. An autonomous agent does not fit that flow. It needs to pay for an API call, buy data, top up compute, execute a trade, or settle a position — at API speed, thousands of times, without a person in the loop.

Four protocol families now address different layers of that problem, and they are complementary rather than competing.

What has not been solved is the economics of per-request settlement. Analysis published in May 2026 showed that naive on-chain settlement per request turns a standard request-response into a five-step flow — challenge, signing, confirmation, retry, response — and the model breaks outright when the transaction fee exceeds the price of the service being bought. The direction the ecosystem is moving is on-chain deposits with off-chain metering and periodic settlement against usage receipts. If you are designing an agent that pays per call, design for batched settlement from day one.

From our engineering practice: what a machine-to-machine settlement layer actually costs

Challenge. A client needed a processing core that could accept inbound transactions from partner systems without a human approving each one. The requirement list looked routine until we mapped it: risk-scoring every inbound operation before crediting a balance, running ongoing automated counterparty checks rather than a one-time screen, managing signing keys, configuring callbacks per partner project, routing conversions through liquidity pools by priority, and giving each partner role a granular permission set. Every one of those is a prerequisite for letting a machine initiate a payment.

Solution. We built the core as a microservice architecture with a single source of truth per entity: partner legal data, per-project cryptocurrency configuration, partner and company balances, liquidity pool balances, and a complete operation log covering both internal transfers and external counterparty settlement. The AML layer runs in two modes — a synchronous risk check on inbound operations that can return funds to the sender, and a background continuous monitoring job that re-labels counterparties as their behavior changes. We duplicated the server infrastructure across a second physical location and set daily backups on every instance, because a settlement core with a single point of failure is not a settlement core. Teams evaluating this layer separately can compare it against a standard how to create crypto payment gateway build, which shares most of the same primitives.

Result. The full processing core came in at $88,000 for the base configuration and $99,000 with payment-provider orchestration, invoice logic, and web checkout. That is the honest cost of the layer that x402, AP2 or MPP would sit on top of. The protocol is the top 5% of the work.

Trend 3 — Agent Identity, Know Your Agent, and Scoped Permissions

In agentic finance the hardest question is not whether the agent made a good decision. It is whether the system can prove the agent was authorized to take that action at all.

A human user has an account, credentials, permissions, and usually a transaction history. An autonomous agent needs an equivalent security model built on delegation rather than identity alone. That is where Know Your Agent starts. Instead of handing an agent broad access to a corporate API or a wallet, you issue scoped, short-lived credentials bound to a specific purpose.

A production permission model needs to express six things, and it needs to express them as data rather than as documentation:

{


  "mandate_id": "mnd_7f3a...",


  "agent_id": "agt_reconciliation_02",


  "principal": "org_4412",


  "spend_cap": { "amount": 2500, "currency": "USDC", "window": "24h" },


  "scope": ["ledger.read", "psp.query", "case.create"],


  "counterparty_allowlist": ["psp_adyen", "psp_worldpay"],


  "expires_at": "2027-03-14T00:00:00Z",


  "revocation_endpoint": "https://api.example.com/mandates/revoke",


  "policy_version": "v4.2.1",


  "approval_required_above": { "amount": 500, "currency": "USDC" }


}

ERC-8004 is one emerging identity layer, offering a portable on-chain agent identifier plus reputation and validation registries. But identity alone does not authorize anything. A known agent with excessive permissions is still dangerous — arguably more dangerous, because its actions look legitimate in the log.

We learned this on a payments platform where the data model stored "agent" as a single role field on the user record. That was not enough. We split it into separately verified specializations, each with its own verification path, its own document requirements, and its own pool of accessible operations. An operator verified for one specialization sees only that pool; unlocking another requires passing that verification independently. The important part is enforcement location: an unverified specialization blocks access at the permission layer on the backend, not by hiding a category in the interface. A hidden button is not access control.

Human-in-the-loop helps, but it cannot be your only control. If every action requires a person, the system loses most of its economic value. The scalable model is policy-bounded autonomy: the agent acts freely inside a predefined envelope and escalates only when it crosses a risk threshold.

Trend 4 — Governance Moves Into the Architecture

By 2027, agent governance stops being a compliance document and becomes an engineering requirement.

The regulatory picture in Europe has already firmed up. The EU published the Digital Omnibus on AI — Regulation (EU) 2026/1744 — in the Official Journal on 24 July 2026, and it entered into force three days later. It moved high-risk obligations for standalone Annex III systems from 2 August 2026 to 2 December 2027, and for AI embedded in products regulated under Annex I to 2 August 2028. What it did not move matters just as much: the Article 50 transparency regime, the general-purpose AI provider obligations, and the prohibited-practices rules all stayed on their original schedule. The deferral is real, and it is narrow.

For US financial teams the practical problem is broader than any single AI statute. Existing expectations around model risk, controls, consumer protection, fraud, explainability and auditability all continue to apply as systems become more autonomous. The classification of your use case, not the label "AI", determines what you owe.

The engineering answer is to make auditability a runtime feature rather than a reporting exercise. Every material agent action should emit a trace like this:

{


  "trace_id": "trc_9b21...",


  "task_id": "case_88413",


  "agent_id": "agt_aml_triage",


  "goal": "triage_alert",


  "inputs": { "alert_id": "alt_5521", "dataset_version": "kyt_2027_02_11" },


  "model": { "name": "claude-sonnet", "version": "4.6" },


  "prompt_version": "aml_triage_v11",


  "tools_called": [


    { "tool": "kyt.screen_wallet", "latency_ms": 512, "result": "risk_score:7.4" },


    { "tool": "ledger.fetch_history", "latency_ms": 88, "result": "142_records" }


  ],


  "authorization": { "mandate_id": "mnd_7f3a...", "policy_version": "v4.2.1" },


  "policy_checks": [ { "rule": "threshold_20pct", "outcome": "triggered" } ],


  "human_review": { "required": true, "reviewer": null, "status": "queued" },


  "final_action": "case_escalated",


  "timestamp": "2027-02-11T14:22:07Z"


}

The goal is not log volume. The goal is enough linkage between decisions to reconstruct why a financially material action happened, months later, in front of someone who was not in the room.

One design detail we keep re-learning: consent and policy acceptance need version-level granularity or the audit trail is worthless. On a platform with multiple business roles, we stored the document ID and version, the role the document applied to, the acceptance timestamp, the user who granted it, and the request attributes. A boolean "accepted" flag tells you nothing when the terms changed twice and three different role types received different documents. The same principle applies directly to agent policy: log which policy version authorized which action, not merely that a policy existed.

Trend 5 — The Unit Economics That Kill 40% of Projects

For CTOs, the surprise in agentic AI is rarely model performance. It is the gap between demo economics and production economics.

A prototype makes one API call, returns a good answer, and looks cheap. Production agents behave differently — they reason repeatedly, call several tools, retry failures, fetch context, verify results, and then take an external action. Gartner's own note is blunt about this: a lower token price does not reduce total AI cost when systems consume far more tokens and reasoning cycles.

The only metric that survives contact with a CFO is cost per completed task:

Suppose an AML agent processes 10,000 investigations. The question is not whether the tokens were cheap. It is whether the entire system costs less than the human process it replaces, at an acceptable false-positive and false-negative rate. A serious business case measures the baseline cost per task, the agent's cost per successfully completed task, the human intervention rate, the error and rework rate, latency, revenue or transaction impact, and operating cost at target volume. Our full breakdown of ai agent development cost walks through how each of those lines scales with agent count and tool surface.

Two numbers are worth separating before you model anything: the cost of building the system once, and the cost of running it per task forever. Most budgets we review conflate them, and our breakdown of how much does it cost to build an ai system separates the two lines explicitly across complexity tiers.

From our engineering practice: real costs and the traps production sets

Challenge. We have delivered agentic proofs of concept and we have run the fintech infrastructure underneath them, and the two budgets look nothing alike. Clients arrive with a POC number in mind and no model for what production adds. Meanwhile the infrastructure itself produces failure modes that never appear in a pilot.

Solution and findings. Three numbers from our own delivery are worth putting side by side.

First, the POC. A hybrid system — six specialist agents, two ML models, vector memory, an adaptive learning loop, a dashboard and notification delivery — took 4 to 6 weeks to reach a working state, with recurring infrastructure of $270–$400 per month covering LLM API usage, embeddings, VPS and database, and paid data subscriptions. That is genuinely inexpensive, and it is why the POC is a decision instrument rather than a development phase.

Second, the production layers that a POC does not include. From our actual estimate files: an automated policy and escalation contour — trigger fires, ticket opens, access freezes, case queues for manual review — runs roughly 240 development hours, about $6,600. Jurisdiction-based restrictions add $2,200. A full analytics and observability module with dashboards, filtering, charting, report export and case analytics costs 452 backend hours and 382 frontend hours, around $23,110 for the web tier alone. Observability is not a rounding error on the agent budget; it is comparable in size to the agent itself. Designing the service boundary that keeps the AI layer independent of core business logic is another 240 hours, roughly $8,640 — fixed, and far cheaper before the first agent ships than after.

Third, runtime. An agentic system in production is not a deployment, it is continuous runtime control. Our support tiers reflect that: one-hour response on working days with 70 development hours a month runs $6,500/month; round-the-clock coverage with 150 hours runs $12,000/month. For an agent taking financially material actions without a human in the loop, that is part of TCO, not an upsell.

Result — and the two failure modes we would warn any team about. On one platform, the database stopped serving requests after it exhausted disk space, leaving a large number of open connections hanging on heavy payloads. There were no alerts on storage utilization or connection count, and metrics were only reachable through a direct connection to a managed instance — meaning any polling added load to the thing we were trying to save. We expanded storage and the system recovered in about five minutes, then raised the database response timeout from 20 to 60 seconds as a stopgap. Our DevOps response SLA on infrastructure incidents runs 30–60 minutes, and that is what kept a five-minute recovery from becoming a five-hour one.

The second failure mode is the one that maps most directly onto agentic systems: we found that features disabled or hidden in the interface were still generating load through background workers. A switched-off feature is not a switched-off resource consumer. For a system where autonomous loops run on a schedule, that is the most expensive possible leak, because nobody monitors what is officially not running.

Trend 6 — Vertical Agents Win in Finance

A vertical agent understands domain terminology, data structures, regulatory constraints, decision thresholds and the consequences of errors. That narrows the space in which the model can improvise, which is precisely the point.

The pattern is identical in all four: autonomy for bounded execution, human control for irreversible or high-risk decisions. The support case is the one teams most often underprice, because an agent with read access to balances is a different product from a scripted assistant — the gap shows up clearly in a realistic ai chatbot development cost breakdown once financial actions enter scope.

Where we have seen this work: compliance triage

On a compliance build we integrated an AI copilot into the KYT workflow. It generated risk summaries and explained graph analysis output, and the compliance officer attached those results to the audit log with an escalation path from analyst to operations manager. The measurable effect was not fewer people — it was lower required seniority per case and case analysis time dropping from hours to minutes. Wallet screening ran at roughly 500ms latency and the design scaled from about 3,000 to 10,000 screenings per month without adding headcount.

The architectural decision that made it usable was scoring format. We replaced categorical low/medium/high flags with a linear 0–10 risk score derived from the proportion of funds originating from risky sources — 10% of exposure maps to a score of 1.0, 95% maps to 9.6. Thresholds and custom triggers stayed configurable without touching the core system. The reason is arithmetic: a single false positive cost about 45 minutes of manual review, and categorical grading multiplies those. The same principle applies to any agent output you plan to act on automatically — make it numeric and calibratable, not a label.

The other half of the design was hybrid document verification. The system compared a submitted document against the original template automatically, and when it found a divergence it showed the administrator the specific line that differed alongside both file versions — not a red "files do not match" status. The administrator retained the right to approve even against a negative automatic verdict, which covers parsing errors, OCR failures and false positives. Automation should accelerate the operator, not remove their authority over the final call.

Trading is the other vertical where bounded autonomy pays off quickly, and teams evaluating that path can compare architectures in our guide on how to create an ai trading bot, which covers execution boundaries and risk-limit enforcement in more depth.

Trend 7 — Smaller Models Take Over Routine Agent Work

The "one giant model for everything" architecture is getting harder to justify. Gartner expects organizations to use small, task-specific models at least three times as often as general-purpose models by 2027.

For an agentic fintech platform that means model routing. A small model classifies a transaction, extracts fields, summarizes a case, or decides which tool to call. A larger model handles ambiguous investigations, complex reconciliations and unusual risk scenarios. We use this split in production — a lighter model for classification work and a stronger one for analytical agents — and it is the single easiest cost lever available.

Routing buys you three things. Cost becomes predictable because expensive inference fires selectively. Privacy improves because sensitive workloads can run on private or on-premise infrastructure instead of an external API — and if that matters to you, the current open source llm leaderboard is a reasonable starting point for evaluating self-hosted candidates. And failure domains shrink: you can evaluate a specialized model against a narrow criterion instead of trusting a general model across dozens of unrelated financial decisions.

Routing decisions also change your provider strategy. Once inference is split across several models, swapping one of them stops being a migration and becomes a configuration change — which is the main reason our llm development engagements start with the routing layer rather than with prompt work.

An effective 2027 architecture is heterogeneous — several models, different sizes, explicit routing rules — rather than one model behind every agent. Teams designing that routing layer usually need to make a related decision about how agents reach context, and our comparison of rag vs mcp covers when each approach is the correct primitive.

Reference Architecture for an Agentic Product in 2027

Design a production agent as a governed software system, not as an LLM wired to an API. Six layers, and each one has a concrete technology answer.

The tool layer deserves more attention than it usually gets. An agent should never receive unrestricted access to an underlying system — every tool exposes narrow functionality with explicitly typed inputs and outputs, and the permission check happens on the server side of that boundary. Teams coming from simpler chat gpt integrations often underestimate this step, because a chat integration reads context while an agent changes state.

From our engineering practice: how we built the memory and data layer

Challenge. A client wanted long/short signals for BTC and ETH with full reasoning transparency, outcome tracking, and measurable improvement over time — delivered as a working POC in 4 to 6 weeks, in paper-trading mode, with honest accuracy validated against real history rather than the inflated numbers most backtest reports carry. The core technical problem was that LLM agents are stateless by default. Without a memory layer, every decision starts from a blank slate, and the system has no idea what it concluded yesterday or how that turned out.

Solution. We ran one PostgreSQL 16 instance with two extensions instead of three separate stores. TimescaleDB handled time-series: hypertables with automatic time partitioning, continuous aggregates, 10–20× compression on historical data, and sub-millisecond aggregation across years of OHLCV. pgvector handled semantic search. We deliberately skipped a dedicated vector database — market data is relational and time-ordered, and the operations that matter most (time-bucketed aggregation, joins on timestamp, window functions for indicators) are SQL-native. Adding Pinecone would have added operational surface with no performance gain on this workload.

That reasoning — pick the storage engine that matches the access pattern rather than the one that matches the trend — is the same one we apply when clients ask about ledger design, and we walk through it in our comparison of private blockchain vs database trade-offs.

pgvector then covered three distinct jobs on the same extension. It searched historical patterns — encoding the current market configuration as a feature vector and retrieving the top-N most similar past situations along with what happened next. It provided agent memory, embedding every signal with its full context, reasoning and eventual outcome so the synthesizer could retrieve comparable past decisions before making a new one. And it deduplicated news against recent clusters, so the system could not count one event three times in sentiment scoring.

On top of that we ran an adaptive learning loop on three timescales. Hourly, the full pipeline executes and logs to PostgreSQL. Daily, an evaluator checks signals from 24, 48 and 72 hours earlier against actual price movement and updates per-agent, per-regime accuracy statistics. Weekly, the ML models retrain and the agent weights recalculate. The hard part was never the retraining — it was building the evaluation layer correctly, with enough granularity to separate regime performance from overall accuracy and without survivorship bias.

Result. Working POC in 4–6 weeks. Directional accuracy under walk-forward validation across 2–3 years of history: 54–58% on a 24-hour horizon. Those numbers are lower than most vendors quote, and they are real — a random train/test split introduces look-ahead bias that evaporates in the first live week. The client received a complete decision history in PostgreSQL: every agent output, every model prediction, every retrieved historical pattern, every final signal, every outcome evaluation. If you want the broader picture of how these pieces price out end to end, our guide on how to create an ai app breaks down architecture decisions and team composition across complexity tiers.

Pilot vs Production: The Infrastructure Gap Nobody Budgets For

This is where most agentic programs stall. The pilot works, and then the production requirements arrive as a second project nobody scoped.

We ran that migration on a fintech platform: 17 microservices rewritten as Docker containers, a single Helm chart across services, HashiCorp Vault integrated with CI through JWT tokens, a horizontal pod autoscaler configured per service, and a Redpanda message bus for inter-service communication. We split the cluster into control plane and worker nodes as it matured.

The decision that saved the most rework was not technical, it was a policy: we defined which services must never autoscale. Order book and wallet services carry state dependencies that make horizontal scaling non-trivial. Writing that policy before the Helm charts, rather than discovering it during a load event, is the difference between a two-week and a two-month migration. The same distinction applies directly to agent runtimes — a stateless tool executor scales horizontally, an agent holding a live session with accumulated context does not. If you want the full picture of how these scaling decisions play out under real trading load, our breakdown of crypto exchange architecture covers partitioning, replication and latency management in detail.

Two things went wrong that are worth knowing in advance. Vault access proved unstable, most likely from configuration auto-rollback — centralizing secrets creates its own point of failure and needs its own monitoring. And environment drift between Docker Compose development environments and a Kubernetes production cluster produced bugs that only surfaced at release. Unifying every environment on the same orchestration is not fashion; it is release quality control.

Failure Modes You Should Design Against

None of these are exotic. Each one below has cost a project we worked on real time or real money, and most of them overlap with the threat model we describe in our guide to crypto exchange security — because an autonomous agent with credentials is, from an attacker's perspective, a privileged service account that reasons.

What to Build in the Next 12 Months

The correct response to agentic AI is not launching ten agents. It is building the infrastructure that lets you measure and control one production agent. Order matters.

Three principles behind that sequence. Choose the process before the model — a strong model cannot rescue a poorly defined workflow. Build observability before autonomy, because if you cannot explain what the agent did in staging you will not defend it in production. And define authority before the first release: the maximum an agent can spend, the systems it can reach, and the actions requiring confirmation all need to exist before it receives credentials. If you are still deciding how deep to go on the integration side, our practical notes on how to integrate ai into an app cover the trade-offs between wrapping an existing product and rebuilding around the agent.

If your team is closer to the start of that sequence than the end, the process questions matter more than the model questions, and our technical guide on how to develop ai software covers the delivery structure we use — baseline run, first critical flow, CI integration, then coverage expansion.

Conclusion

The expensive gap in 2027 will not sit between companies that use AI and companies that do not. It will sit between teams that built infrastructure for controlled autonomy and teams that bolted autonomy onto systems designed for human interaction.

That means investing in the unglamorous parts: scoped identity, policy enforcement, durable state, observability, model routing, payment protocols, and unit economics you can actually defend. Models will keep changing. The infrastructure decisions you make now will outlast three model generations.

We build these systems as production software — AI, financial infrastructure and automation working as one deployable stack rather than as a chatbot feature bolted to a ledger. If you are scoping an agentic build and want a per-module hour breakdown against your actual process, that is the conversation we are useful in. Our enterprise ai development practice covers architecture review, POC delivery and production hardening as separate engagements, so you can start where the risk is.

FAQ

• What is the difference between agentic AI and generative AI?

  Generative AI produces content or recommendations in response to a prompt. Agentic AI uses a model inside a decision loop that plans, calls tools, evaluates results and takes action with limited human involvement. The practical difference is the failure mode: generative AI produces a bad answer, agentic AI takes a wrong action.

• Is it safe to let AI agents handle payments?

  Only when autonomy is bounded by identity, authorization, spend caps, policy enforcement and auditability. An agent should hold short-lived credentials scoped to a specific purpose with an explicit spend mandate, a counterparty allowlist, an expiry and a revocation endpoint. Identity alone is not authorization — a known agent with excessive permissions is still dangerous.

• How much does it cost to build an AI agent for a fintech product?

  A working proof of concept with specialist agents, vector memory and a learning loop takes 4–6 weeks with recurring infrastructure of roughly $270–$400 per month. Production adds the layers that make it defensible: a policy and escalation contour around $6,600, jurisdiction rules around $2,200, and an observability module around $23,110 for the web tier. The right business metric is cost per completed task, not cost per token.

• What is the x402 protocol and why does it matter for AI agents?

  x402 is an HTTP-based payment protocol that lets clients, including agents, pay for resources programmatically without accounts, sessions or API keys. A service returns HTTP 402 with payment requirements, the client submits a signed payment, and the server verifies and completes the request. It moved under Linux Foundation stewardship in July 2026 and AWS added it to Bedrock AgentCore Payments in May 2026, so it is no longer an experiment.

• Do we need a multi-agent system, or is one agent enough?

  One agent is usually enough when a single bounded workflow runs reliably with a small number of tools and decisions. Multi-agent architecture earns its complexity when the task splits naturally into specialist domains such as KYC, risk and reconciliation. The threshold is not task difficulty — it is whether the domains require genuinely different reasoning and different accuracy tracking.

• Which agentic AI use cases actually work in finance today?

  The strongest are AML alert triage, reconciliation, risk monitoring and supervised customer support. All four combine structured data, repeated decisions and a measurable outcome, which is exactly what an agent needs to be evaluated against. Open-ended advisory work and anything requiring an irreversible judgement call remains a human gate.

• How long does a production agentic system take to build?

  A working POC takes 4–6 weeks when the architecture is defined upfront. Production readiness — scoped permissions, deterministic policy checks, observability, isolated staging and a runtime SLA — typically adds another two to four months depending on how many external systems the agent touches. Full fintech platforms with a complete control plane run well past six months.

• Do we need MCP, or is RAG enough?

  They solve different problems. RAG gives an agent access to knowledge; MCP standardizes how you expose tools and actions to it. If your agent only needs to read context, retrieval is sufficient. Once it needs to take actions across multiple systems with consistent typing and permission boundaries, a standardized tool layer starts paying for itself.

• How do you test an AI agent before production?

  Model it as a state graph rather than a list of allowed actions, then verify the invariants that must hold after a sequence of operations — for a balance operation, that means checking the resulting balance against the arithmetic, not the HTTP status code. Run generated sequences repeatedly against an isolated staging environment with resettable accounts, and log with enough structure and a stored seed that any failure reproduces exactly.

• Does the EU AI Act delay give us more time?

  Less than it appears. Regulation (EU) 2026/1744 moved high-risk obligations for standalone Annex III systems to 2 December 2027 and to 2 August 2028 for AI embedded in regulated products, but the Article 50 transparency regime, GPAI provider obligations and prohibited-practices rules all stayed on their original schedule. For US teams, existing model risk, explainability and auditability expectations apply regardless.

• What happens when the LLM provider changes or deprecates a model?

  This is why the AI layer should sit behind a service boundary rather than inside your backend. Keep prompts versioned, log the model name and version on every trace, and maintain a routing layer that can direct workloads to a different model without touching business logic. Teams that hardcode a provider into their core service pay for that decision at every model generation.

• How much of an agentic budget goes to maintenance rather than development?

  In our agentic work, roughly 25–30% of ongoing maintenance effort was data resilience rather than ML logic — handling provider outages, changed methodologies and recalibrated upstream scoring. Add runtime support on top: one-hour response coverage runs about $6,500 per month and round-the-clock coverage about $12,000. Budget both explicitly or they surface as unplanned cost in month three.