DEV Community: Dextra Labs

Building AI-Powered Payment Support Workflows for Modern Customer Service Teams

Dextra Labs — Wed, 30 Sep 2026 17:52:55 +0000

Most payment support automation stops at the chatbot layer. A customer asks about a failed charge, and the bot explains the refund policy. That is text generation, not workflow execution, and the gap between the two is where the real engineering challenge lives.

The interesting problem is not generating a response. It is building a system that can identify a customer, inspect payment records, check policy, execute an action through an API, verify the result, and update the support ticket, all within a controlled, auditable workflow.

In this blog, we walk through the architecture, integrations, failure handling, and security guardrails required to build AI-powered payment support workflows that actually do the work rather than just talk about it.

Payment Support Is a Workflow Problem, Not Just a Chatbot Problem

Consider a familiar support scenario: "I was charged twice. Can you refund one of the payments?"

A basic chatbot can explain the refund policy. An AI-powered workflow needs to actually identify the customer, inspect payment records, verify eligibility, check whether automation is permitted, execute the refund, update the support system, and respond with the outcome.

The difference becomes clear when you compare the two approaches. Traditional support follows a path where the customer message reaches an agent, who searches systems, checks the payment, takes the action, and updates the ticket. An AI-powered workflow follows a longer but more structured path: the customer request triggers intent detection, which pulls payment data, runs a policy check, executes the action, verifies the result, updates the ticket, and sends the response.

DEV readers will immediately recognize that the interesting engineering problem here is workflow execution, not text generation. As Dextra Labs' guide to AI agents for customer service explains, this execution-oriented pattern is increasingly central to how production support agents are being built.

Which Payment Support Tasks Are Worth Automating?

Not every payment conversation should be automated. The right starting point is repeatable, measurable workflows where the steps and decision logic are well defined.

Start with the tasks that have clear inputs, predictable steps, and measurable outcomes before expanding into more complex or ambiguous conversations.

Architecture of an AI Payment Support Workflow

This is where engineering gets interesting. A production AI agents for payment processing workflow typically follows a layered architecture where the customer message flows through intent classification, then into customer and payment context retrieval, through a policy and eligibility engine, into an action planner, out through payment, CRM, and ticketing APIs, through a verification step, into an audit log, and finally back as a customer response.

Each layer has a specific responsibility:

Intent layer: Identifies whether the request is a refund, failed payment, duplicate charge, invoice question, dispute, or something else.
Context layer: Retrieves customer, invoice, transaction, and subscription information from connected systems.
Policy layer: Determines what the agent is allowed to do based on business rules, thresholds, and customer state.
Action layer: Calls payment and business APIs to execute the permitted action.
Verification layer: Confirms that the action actually succeeded at the payment provider.
Audit layer: Records what happened, what was decided, and why.

A key engineering principle: the LLM should interpret requests and coordinate tools, while deterministic business rules enforce what the system is allowed to do. Policy enforcement belongs outside the probabilistic model.

Connecting the Agent to Payment and Support Systems

The agent becomes useful only when it can access the systems where the actual work happens.

Typical integrations:

Payment processor APIs (Stripe, Adyen, Razorpay, etc.)
Billing and subscription platform
CRM and customer database
Helpdesk and ticketing system
Order management system
Internal policy and knowledge base

A typical workflow calls a sequence like:

get_customer()
get_transactions()
check_refund_policy()
create_refund()
update_ticket()
send_customer_message()

Tools should expose narrow, permissioned operations rather than unrestricted database or payment access. For sensitive payment information, the workflow should use payment-provider tokens, IDs, and approved APIs rather than giving the LLM direct access to raw payment credentials.

Example: Automating a Duplicate-Charge Request

Rather than several shallow examples, here is one concrete workflow from start to finish.

Customer message: "I was charged twice for my subscription this month."

Workflow steps:

Identify the customer from the support session.
Retrieve recent successful transactions.
Compare amount, invoice, timestamp, and transaction status.
Determine whether the second charge is genuinely duplicated.
Retrieve the applicable refund policy.
Check the automated-refund threshold.
Execute the refund if permitted.
Verify the payment provider's response.
Add an internal ticket note.
Send the customer the outcome.

The decision structure looks something like:

json
{
  "intent": "duplicate_charge",
  "duplicate_confirmed": true,
  "refund_allowed": true,
  "requires_approval": false
}

Where Human Approval Should Stay in the Loop

Human-in-the-loop is not a weakness. It is an architectural control, and payment workflows need it in specific places.

Good candidates for human review:

High-value refunds above the automated threshold
Ambiguous duplicate-payment cases
Chargeback disputes requiring judgment
Suspected fraud
Policy exceptions
Account ownership uncertainty
Irreversible financial actions
Conflicting customer or payment data

The pattern is straightforward: low-risk requests that pass policy checks proceed to automated action, while high-risk or ambiguous requests route to human review. The agent should pause rather than guess when required information is missing or contradictory.

Designing for Failures, Retries, and Idempotency

Payment workflows cannot assume every API call succeeds. The system needs to handle:

Payment API timeouts
Duplicate webhooks
Partial workflow completion
Stale customer data
Failed refund attempts
CRM unavailability
Conflicting payment states
Network retries creating duplicate actions

Consider a refund request where the payment API times out. The system retries with an idempotency key, then verifies the actual transaction state before proceeding. If the refund succeeded, the ticket is updated.
If it failed, the case escalates to a human agent.

Idempotency, state management, retries, and explicit failure states are essential when an AI agent can trigger financial actions. Without them, a retry can become a double refund.

Security and Guardrails for Payment AI Agents

Keep this practical. The guardrails that matter most for payment workflows:

Least-privilege tool permissions
API-level authorization for every action
Refund and transaction limits
Customer identity verification before any action
Sensitive-data filtering (no raw card numbers in logs or LLM context)
Deterministic policy enforcement
Action logging with full traceability
Human approval thresholds
Kill switches for immediate workflow shutdown

A useful principle: never let the LLM be the final authority for a financial action. The model can interpret an instruction, but permissions and transaction constraints should be enforced by application code.

Measuring Whether the Workflow Actually Works

Move beyond "accuracy" and measure the entire workflow end to end.

An AI support workflow should be evaluated on successful task completion, not merely how convincing its responses sound.

Start With One Payment Workflow, Then Expand

The strongest implementation approach for custom AI agent development services in payment support follows a phased progression:

Phase 1: Automate read-only payment-status questions.
Phase 2: Add policy-driven, low-risk actions such as small refunds.
Phase 3: Introduce human approval for higher-risk actions.
Phase 4: Add proactive workflows such as failed-payment recovery and dispute preparation.
Phase 5: Continuously evaluate logs, failures, and customer outcomes.

This aligns with the broader 2026 pattern of starting with a narrowly defined workflow, connecting the required tools, and expanding only after the workflow is measurable and reliable.

Technical Due Diligence Errors That Can Kill an M&A Deal

Dextra Labs — Tue, 29 Sep 2026 10:50:36 +0000

If you've been an engineer long enough, one day someone from the business side will pull you into a call, share a private repo you've never seen, and ask a question that sounds simple and isn't:

"So… is this codebase okay? We're thinking of buying the company."

That question is technical due diligence. And the honest answer is almost never "yes" or "no", it's "okay for what, and at what cost?" Because the people asking are about to move real money based on your read of a system you've had for about a week.

Here's the thing nobody tells the engineer in that seat: a deal can survive a bad negotiation. It can survive a mediocre earn-out or a clumsy term sheet. What it often can't survive is a technology risk nobody saw until after signing.

A target looks great on paper, recurring revenue, customer growth, "proprietary" software, an AI story, a big engineering team. Then diligence (or worse, post-close reality) turns up the stuff that changes the math:

the architecture can't take the projected growth
source-code ownership is… complicated
the technical debt is really a rewrite wearing a trench coat
there are security holes that come with legal liability attached
cloud costs were modelled by an optimist
two engineers are load-bearing walls
the "AI" is a thin shell over someone else's API
integration is 3× harder than the deck implied

The whole job of technical due diligence is to surface that stuff before signing, while the buyer can still price it, negotiate it, or walk. TDD exists to reduce uncertainty before the deal depends on closing, not to document surprises after.

So here are the errors I see kill deals, roughly in the order they tend to happen.

First, what Technical DD actually is (it's not a code review)

Quick baseline, because half the technical due diligence mistakes below come from getting this wrong.

Technical diligence helps a buyer understand what they're actually acquiring, whether it works as represented, how well it scales, what the risks are, what remediation will cost, whether the tech supports the reason for the deal, and how painful integration will be.

And critically, it is not a code review. A real review spans the whole estate:

Code → Architecture → Infrastructure → Security → Data → IP → Engineering → Vendors → Roadmap

You're not grading a pull request. You're assessing an operating technology environment that a business is about to depend on. Keep that scope in your head, most of the failures below are really just people quietly shrinking it back down to "read the code."

1. Starting too late

The single most damaging error: bringing technical people in after the commercial assumptions are already locked.

By the time the engineer gets access, the deal team has often already agreed the valuation, drafted the integration plan, estimated synergies, and negotiated the big terms. Then diligence turns up something material, and now you're not informing the deal, you're detonating it.

Late findings trigger valuation renegotiation, extra warranties, escrow demands, integration-cost revisions, delays, and a lot of tense calls between buyer and seller who both thought this was done.

- TDD as a box to tick before close
+ TDD early enough that findings can still change the deal

If the diligence can't influence the terms, it's not diligence. It's archaeology with a deadline.

2. Treating TDD as a code review

Reading the source matters. It just doesn't tell you the whole story, and betting a deal on it alone is how buyers get blindsided.

A code-only pass reliably misses cloud architecture, infrastructure costs, cybersecurity, IP ownership, third-party dependencies, key-person risk, vendor contracts, data architecture, scalability, and integration complexity. You can have clean, elegant code and still be buying a disaster.

The mental model that fixes it:

Application + Infrastructure + Data + Security + People + IP + Vendors + Operations

You are acquiring an operating environment, not a git clone. The code is one file in the repo.

3. Not separating deal-killing risk from ordinary backlog

A report with 100 technical findings is not useful to a deal team. It's noise with a page count.

The only question that matters to the people signing is: which of these could actually move the transaction? So sort findings by business impact, not by how much they annoy you as an engineer:

Then translate each one into money:

Legacy architecture → modernization cost
Poor scalability → infrastructure investment
Security weakness → remediation plus potential liability
IP ownership gap → legal and transaction risk

That translation is what turns a technical report into a decision tool. A finding with no dollar figure and no severity is just trivia.

4. Underestimating technical debt

Every engineer instinctively over-indexes on debt because we're the ones who live with it. But not all debt is a deal-killer, and treating it that way makes you the person who tanks good deals over // TODO: refactor this.

The distinction that matters:

Manageable debt is documented, prioritised, understood by the team, and compatible with the roadmap. Fine. Normal. Every real codebase has it.

Material debt is undocumented, everywhere, actively blocking product work, causing reliability problems, and heading toward "we need to replace the architecture." That's the kind that shows up in the integration budget as a nasty surprise.

Questions worth asking the target's engineers directly:

How much debt is there, and where's it concentrated?
Why was it created? (Deliberate speed, or nobody was watching?)
Does it affect scalability?
Is remediation already budgeted?
Will it interfere with integration?
How many engineer-months to resolve the serious parts?

The answers tell you whether you're looking at a healthy fast-moving codebase or a bill nobody's added up yet.

5. Assuming they own what they built

A buyer will happily assume that acquiring a software company means acquiring all its software. That assumption has ended careers.

Audit ownership: employee IP assignments, contractor agreements, outsourced development, founder contributions, patents, proprietary algorithms, and who actually controls the repos.

Audit dependencies: open-source (and its licences, copyleft is not your friend at signing), commercial libraries, APIs, cloud providers, AI models, third-party data, software licences.

Why it reaches all the way to the closing table: an ownership or licensing gap can blow up the transaction representations, the warranties, the valuation, transferability, and the integration plan. "We built it" and "we own it" are different sentences, and diligence is where you find out which one is true.

6. Running the same generic checklist on every deal

A technology due diligence checklist gives you structure, and structure is good. But running the identical checklist on every acquisition means you spend time on low-impact boxes while missing the risks specific to this target's stack and business model.

Different deals need different depth:

SaaS → multi-tenancy, scalability, cloud economics, customer data isolation, recurring infra costs.

AI-native → model architecture, training data, model dependencies, inference costs, eval methodology, data rights, foundation-model reliance.

Fintech → security, data governance, regtech, legacy transaction systems, infrastructure.

Start from a standard framework, then customise it against the industry, the tech, the deal structure, the thesis, the regulatory exposure, and the integration goals. A checklist you didn't adapt is a checklist that's quietly looking in the wrong place.

7. Never checking the tech against the deal thesis

This is the M&A-specific miss, and it's a big one. Diligence should answer more than "is the technology healthy?" It has to answer: can this technology support the reason we're buying the company?

Same codebase, three different theses, three different reviews:

Growth / international scale → architecture, infrastructure, localization, data residency, reliability.
Cost synergy → application duplication, cloud spend, vendor contracts, infra consolidation.
Technology acquisition (acqui-hire / IP) → proprietary IP, code quality, technical differentiation, engineering capability, roadmap.

If you assess a cost-synergy deal like a growth deal, you'll write a beautiful report that answers the wrong question. Anchor the diligence to why the buyer is doing this at all.

8. Skipping cybersecurity and data risk

A product can pass every functional test and still be a liability the moment you own it.

Look hard at vulnerability management, IAM, encryption, secrets management (please, check for the .env committed in 2021), cloud security, incident response, data protection, backup/recovery, and monitoring.

And ask the pointed questions:

Have there been material security incidents, and were they disclosed?
Are there critical unresolved vulnerabilities?
Who has privileged access, and should they?
Is customer data actually protected, or just stored?
Are the controls appropriate for the industry, not just the stage?
Will security requirements jump after integration into a bigger, more-targeted company?

Post-close breaches are expensive in cash, churn, regulators, and reputation — all at once. This is not the section to skim.

9. Ignoring the bus factor

A platform can rest almost entirely on a few people, and that risk doesn't show up anywhere in the code.

Ask: who actually understands the critical systems? How dependent is everything on the CTO? Who maintains core infra? Which systems are undocumented? What happens if the two people who get it take the acquisition payout and leave? Can the buyer even retain them? Is the team big enough for the roadmap they're promising?

If one or two people are the only ones who understand a critical system, you're not acquiring a platform. You're acquiring their goodwill, on a month-to-month basis.

This matters most when the whole thesis depends on the target's tech keeping the lights on immediately after close, which is most of the time.

10. Treating AI like conventional software

If the target is AI-native, the standard software checklist isn't enough, there's a whole extra surface to assess: training data and its provenance, model ownership, foundation-model dependencies, inference costs, real-world model performance, evaluation methodology, fine-tuning, MLOps maturity, model security, and third-party API reliance.
And watch the economics especially, because this is where AI deals quietly break:

Impressive demo
  ├─ high inference cost per request
  ├─ expensive GPU footprint
  ├─ mediocre model efficiency
  └─ heavy dependency on one external provider
        └─ who can change pricing or pull access anytime
= margins that evaporate at scale

A model that dazzles in the demo can have unit economics that make the business model impossible at volume. AI-native deals may need reviewers who actually know model architecture, data pipelines, and inference economics, leading technical due diligence services for AI startups exist precisely to push the review past conventional code-and-architecture into the AI-specific risks.

11. Never translating findings into deal decisions

A technically brilliant report that a deal team can't act on has failed. The chain that makes it useful:

Finding → Business impact → Financial impact → Deal implication

Worked example:

Finding: legacy infrastructure can't support projected growth.
Business impact: major modernization required.
Financial impact: significant additional technology investment.
Deal implication: revisit the integration budget and the value-creation assumptions.

Every finding in the final report should answer six things: what matters, why it matters, how much it could cost, how fast it has to be fixed, who owns the fix, and whether it affects the transaction. If a finding can't answer those, it belongs in a backlog, not a deal memo.

The anti-error checklist

Turn the mistakes into a process:

- Start early before the assumptions harden.
- Define the thesis know what the tech has to deliver.
- Customise the scope industry, tech, transaction, risk.
- Assess the whole estate not just the code.
- Prioritise material risk separate critical from backlog.
- Quantify remediation cost, time, people, infra, integration.
- Connect to the deal valuation, terms, integration, post-close spend, risk allocation.

A pre-closing checklist you can actually paste into a doc

Technology

Architecture reviewed
Codebase assessed
Technical debt identified
Scalability tested
Infrastructure evaluated

Security

Vulnerabilities reviewed
Security controls assessed
Data protection evaluated
Incident history reviewed

IP & dependencies

IP ownership verified
Contractor agreements checked
Open-source dependencies reviewed
Third-party licences assessed
Critical vendor dependencies identified

Engineering

Team structure reviewed
Key-person dependencies identified
Technical leadership assessed
Retention requirements understood

Integration

Integration complexity estimated
Duplicate systems identified
Migration requirements mapped
Post-close roadmap established

A quick aside from the trenches: if your deal has any of the scary-shaped risks above, gnarly architecture, an AI stack, real security exposure, this is the point where a specialist earns their fee. Good technology due diligence partners like Dextra Labs can hand you a prioritised list of "this is a Tuesday fix" vs. "this is why the margins don't work," instead of a 60-item spreadsheet of undifferentiated red. A findings list with no priorities isn't diligence, it's console.error on the whole codebase.

The bottom line

Technical due diligence doesn't exist to make an acquisition look risk-free. Nothing makes an acquisition risk-free. Its job is to surface the material technology risks early enough that the buyer can understand them, price them, negotiate them, or fix them.

The biggest failure was never "we found technical debt." Every company has technical debt.

The biggest failure is finding out, the week after signing, that the technology is far more expensive, more fragile, harder to integrate, or more dependent on two irreplaceable people than anyone in the deal room assumed.

Find it early Price it honestly, then decide.

Building an AI-Powered Compliance Monitoring System for Financial Institutions

Dextra Labs — Thu, 24 Sep 2026 08:12:19 +0000

We are going to walk through the architecture of a compliance monitoring system we built for a mid-size bank. Not the strategy deck version. The engineering version, with the data pipeline design, the agent architecture, the audit trail implementation, and the parts that took three times longer than we estimated.

If you're an engineer building for financial services, compliance monitoring is probably the project your CTO will ask about next quarter. The regulatory pressure is intensifying, the manual monitoring approach is hitting its capacity ceiling, and the gap between what regulators expect and what batch-review processes deliver is widening every month.

The AI agents in finance space has matured past experimentation. Banks are running agent-based compliance systems in production. But the engineering content around how to build them is thin, most of what's published is either vendor marketing or regulatory theory. This is the builder's perspective.

The problem in engineering terms

Compliance monitoring in a financial institution means evaluating every transaction and operational event against applicable regulations, internal policies, and risk thresholds. The key word is every.

A mid-size bank processing 200,000 transactions daily against roughly 150 distinct regulatory rules across AML, sanctions, lending compliance, consumer protection, and internal policy creates a monitoring matrix of 30 million evaluations per day. The manual approach, sampling 5 percent of transactions for human review, covers 1.5 million of those evaluations. The other 28.5 million go unmonitored until something draws attention to them.

The engineering challenge isn't AI sophistication. It's building a system that performs 30 million evaluations daily with sub-minute latency on new transactions, maintains complete audit trails for every evaluation, handles rule changes without system downtime, distinguishes genuine violations from false positives at a rate that doesn't overwhelm the compliance team, and satisfies regulators that the monitoring is comprehensive, documented, and explainable.

That's a systems engineering problem with AI components, not an AI problem with systems requirements.

The four-agent architecture

The system runs four specialised agents coordinated through a central orchestration layer. Each agent has a bounded scope, defined inputs and outputs, and its own audit trail stream.

                    ┌─────────────────────┐
                    │   Orchestration      │
                    │   Engine             │
                    └──────────┬──────────┘
                               │
            ┌──────────────────┼──────────────────┐
            │                  │                   │
            ▼                  ▼                   ▼
   ┌────────────────┐ ┌────────────────┐ ┌────────────────┐
   │  Transaction    │ │  Regulatory    │ │  Policy        │
   │  Monitor       │ │  Change Agent  │ │  Compliance    │
   │  Agent         │ │                │ │  Agent         │
   └────────────────┘ └────────────────┘ └────────────────┘
            │                  │                   │
            └──────────────────┼──────────────────┘
                               │
                    ┌──────────▼──────────┐
                    │   Audit Trail       │
                    │   Engine            │
                    └─────────────────────┘

A fourth agent, the audit readiness agent, operates on a batch schedule rather than in real time, assembling examination evidence packages from the audit trail. I'll cover it separately because its architecture is fundamentally different from the real-time agents.

Agent 1: Transaction monitoring

The transaction monitor evaluates every transaction against the full applicable rule set in real time. This is the highest-throughput component and the one where architectural decisions have the most direct performance impact.

The naive approach, sending every transaction through an LLM for compliance evaluation, fails at this scale on three dimensions: latency (LLM inference adds 500ms to 2s per evaluation), cost (200,000 daily transactions at inference pricing burns through budget), and determinism (LLM outputs on clear-cut regulatory rules aren't perfectly consistent, which regulators won't accept).

The architecture that works splits the evaluation into two tiers.

The deterministic tier handles rules that have clear, binary answers. Transaction amount exceeds the $10,000 CTR reporting threshold, yes or no. Counterparty appears on the OFAC sanctions list, yes or no. Transaction geographic origin falls in a restricted jurisdiction, yes or no. These evaluations are rules-based, not AI-based. They run as a streaming rules engine against each transaction event.

# Deterministic compliance checks - no AI needed
class DeterministicComplianceEngine:
    def __init__(self, rule_set: RuleSet):
        self.rules = rule_set

    def evaluate(self, transaction: Transaction) -> list[ComplianceResult]:
        results = []
        for rule in self.rules.get_applicable(transaction):
            result = ComplianceResult(
                rule_id=rule.id,
                transaction_id=transaction.id,
                passed=rule.evaluate(transaction),
                evaluation_type="deterministic",
                timestamp=datetime.utcnow(),
                evidence=rule.get_evidence(transaction)
            )
            results.append(result)
        return results

The AI tier handles evaluations that require interpretation. Is this sequence of transactions consistent with normal business activity or does it suggest structuring? Does this customer's recent behaviour represent a legitimate change in financial patterns or a potential account compromise? Does this transaction narrative contain information that contradicts the stated transaction purpose?

These evaluations use an LLM with a structured prompt that includes the transaction data, the relevant regulatory context, and the customer's behavioural baseline. The output is structured, a classification, a confidence score, and a reasoning chain.

# AI-assisted compliance evaluation for pattern-based rules
class AIComplianceEvaluator:
    def __init__(self, model_client, prompt_templates):
        self.client = model_client
        self.templates = prompt_templates

    def evaluate_pattern(
        self, 
        transaction: Transaction,
        customer_history: CustomerHistory,
        rule: PatternRule
    ) -> ComplianceResult:
        prompt = self.templates.render(
            rule_type=rule.type,
            transaction=transaction.to_context(),
            history=customer_history.recent_summary(),
            regulatory_context=rule.regulatory_text,
            output_schema="classification, confidence, reasoning"
        )

        response = self.client.complete(
            prompt=prompt,
            temperature=0.1,  # Near-deterministic for compliance
            max_tokens=500
        )

        parsed = self.parse_structured_response(response)

        return ComplianceResult(
            rule_id=rule.id,
            transaction_id=transaction.id,
            passed=parsed.classification == "compliant",
            confidence=parsed.confidence,
            reasoning=parsed.reasoning,
            evaluation_type="ai_assisted",
            timestamp=datetime.utcnow(),
            model_version=self.client.model_version,
            prompt_hash=hash(prompt)
        )

The temperature=0.1 is deliberate and non-negotiable for compliance evaluations. We need near-deterministic outputs. We also store the prompt_hash and model_version in every evaluation result because regulators need to reproduce the conditions under which any specific evaluation was made.

The split between deterministic and AI tiers is the design decision that makes the system viable at scale. In our deployment, roughly 85 percent of evaluations are deterministic, clear rules applied to structured data. The remaining 15 percent go through the AI tier. This means LLM inference runs on 30,000 transactions per day rather than 200,000, which changes the cost and latency picture entirely.

Agent 2: Regulatory change monitoring

This agent scans regulatory publications and identifies changes relevant to the institution's operations. It's the most straightforward AI application in the system and the one that delivers value fastest.

The data pipeline ingests publications from the institution's applicable regulators, federal register entries, supervisory letters, guidance documents, enforcement actions, consent orders. For US banking, that's the OCC, FDIC, Federal Reserve, CFPB, and FinCEN at minimum, plus state regulators for the institution's operating jurisdictions.

# Regulatory change monitoring pipeline
class RegulatoryChangeAgent:
    def __init__(self, sources, relevance_model, institution_profile):
        self.sources = sources  # RSS feeds, API endpoints, scrapers
        self.model = relevance_model
        self.profile = institution_profile

    def scan(self) -> list[RegulatoryChange]:
        new_publications = []
        for source in self.sources:
            new_publications.extend(source.fetch_since_last_scan())

        relevant_changes = []
        for pub in new_publications:
            assessment = self.model.assess_relevance(
                publication=pub,
                institution_products=self.profile.products,
                institution_jurisdictions=self.profile.jurisdictions,
                institution_charter=self.profile.charter_type
            )

            if assessment.relevance_score > 0.6:
                change = RegulatoryChange(
                    source=pub.source,
                    publication_date=pub.date,
                    summary=assessment.summary,
                    affected_products=assessment.affected_products,
                    affected_rules=assessment.affected_rules,
                    recommended_actions=assessment.actions,
                    relevance_score=assessment.relevance_score,
                    urgency=assessment.urgency_classification
                )
                relevant_changes.append(change)

        return relevant_changes

The relevance model isn't trying to interpret the law. It's classifying whether a publication is relevant to this specific institution's products, services, and jurisdictions, and identifying which internal policies and monitoring rules might need updating. The compliance team makes the interpretive decisions, the agent surfaces what they need to see.

This agent runs on a scheduled basis, every six hours for federal sources, daily for state sources. The latency tolerance is hours, not seconds, which means it can use larger models with longer inference times for better classification quality.

Agent 3: Policy compliance monitoring

The policy compliance agent monitors internal operations against the institution's own policies and procedures, employee trading restrictions, information barriers, approval authority limits, customer communication standards.

The architecture mirrors the transaction monitor's two-tier approach. Deterministic checks for clear policy rules (approval authority thresholds, mandatory cooling-off periods, prohibited activity lists). AI-assisted evaluation for policies that require interpretation (communication tone compliance, conflict of interest assessment, information barrier monitoring across communication channels).

The data sources are broader than transaction data, email metadata, internal messaging, access logs, trading activity, document access patterns. The AI compliance monitoring architecture for policy compliance requires integration with communication platforms, HR systems, and access management infrastructure alongside the financial systems.

# Policy compliance - information barrier monitoring
class InformationBarrierMonitor:
    def __init__(self, barrier_config, communication_feed, model):
        self.barriers = barrier_config
        self.feed = communication_feed
        self.model = model

    def evaluate_communication(
        self, event: CommunicationEvent
    ) -> Optional[PolicyAlert]:
        # Deterministic check: are participants in restricted groups?
        sender_group = self.barriers.get_group(event.sender)
        recipient_groups = [
            self.barriers.get_group(r) for r in event.recipients
        ]

        barrier_crossed = any(
            self.barriers.is_restricted(sender_group, rg)
            for rg in recipient_groups
        )

        if not barrier_crossed:
            return None  # No barrier concern

        # AI assessment: does the communication content
        # contain material non-public information?
        content_assessment = self.model.assess(
            content_summary=event.content_summary,  # Never full content
            sender_role=event.sender_role,
            context="information_barrier_evaluation",
            output_schema="risk_level, reasoning, recommended_action"
        )

        if content_assessment.risk_level in ["high", "critical"]:
            return PolicyAlert(
                alert_type="information_barrier",
                severity=content_assessment.risk_level,
                participants=event.participants,
                reasoning=content_assessment.reasoning,
                recommended_action=content_assessment.recommended_action,
                timestamp=datetime.utcnow()
            )

A critical design note in the code above: the AI model receives content_summary rather than the full communication content. In regulated environments, the compliance monitoring system itself must respect data handling restrictions. The model assesses risk indicators, not reads everyone's email. This privacy-by-design approach is a regulatory requirement, not an engineering nicety.

The audit trail engine

The audit trail isn't a logging feature. It's the primary deliverable. Everything the system produces, every deterministic evaluation, every AI-assisted assessment, every alert generated, every human decision on an escalated case, flows into an immutable audit store.

# Audit trail, immutable, complete, reproducible
@dataclass
class AuditRecord:
    record_id: str
    timestamp: datetime
    event_type: str  # evaluation, alert, escalation, resolution
    agent_id: str

    # What was evaluated
    subject_id: str  # transaction_id, communication_id, etc.
    subject_data_hash: str  # Hash of the input data

    # How it was evaluated
    evaluation_type: str  # deterministic, ai_assisted
    rule_id: str
    model_version: Optional[str]  # For AI evaluations
    prompt_hash: Optional[str]  # For reproducibility

    # What was concluded
    result: str  # compliant, non_compliant, escalated
    confidence: Optional[float]
    reasoning: Optional[str]

    # What happened next
    action_taken: str
    human_reviewer: Optional[str]
    human_decision: Optional[str]
    human_decision_timestamp: Optional[datetime]

The subject_data_hash and prompt_hash fields are the reproducibility mechanism. If a regulator asks "why was this transaction evaluated as compliant on March 15th," the audit record contains the hash of the exact data that was evaluated and the exact prompt that was used. The original data can be retrieved and the evaluation can be reproduced with the same model version.

The audit store uses append-only storage, records are never modified or deleted. The retention period matches regulatory requirements, typically seven to ten years for banking. We use a combination of a hot tier (last 90 days in PostgreSQL for fast querying) and a cold tier (older records in S3 with Parquet format for cost-efficient long-term storage).

The audit readiness agent

The fourth agent operates on a batch schedule, weekly and on-demand, rather than in real time. It assembles examination evidence packages from the audit trail, organised against specific regulatory examination modules.

When an examination notice arrives, the compliance team specifies which examination modules apply. The agent queries the audit trail for the relevant time period, assembles the evidence for each module, transaction monitoring coverage statistics, alert volumes and resolution outcomes, rule change history, policy compliance metrics and produces a structured evidence package that the examination team can review.

This is the agent that turned six weeks of examination preparation into four days for one institution we worked with. The evidence already existed in the audit trail. The agent's job was assembly and formatting, not investigation.

The engineering lessons that cost us the most time

Three things took longer than estimated and are worth knowing before you start.

The deterministic rule engine was harder than it looked because regulatory rules aren't as deterministic as they appear in the regulation text. A rule that says "transactions exceeding $10,000" seems binary. Then you discover that the $10,000 threshold applies to aggregated transactions within a 24-hour window from the same customer, that the aggregation logic must account for transactions across multiple accounts held by the same beneficial owner, and that "same customer" has a specific legal definition that doesn't map cleanly to your customer ID field. What looked like a simple threshold check became a multi-step aggregation query with entity resolution.

Model consistency monitoring consumed more engineering effort than model development. In a compliance context, you need to prove that the AI tier produces consistent results over time, that the same input evaluated today produces the same result it would have produced last month. We built a regression testing pipeline that re-evaluates a golden test set of 500 labelled transactions against every model update and every prompt change. If the evaluation results drift beyond a defined threshold, the update is blocked. This pipeline took three weeks to build. It runs automatically and has blocked two updates that would have changed evaluation behaviour in ways the compliance team hadn't reviewed.

Integration with legacy communication systems for policy monitoring was the longest single engineering task. The bank's internal communication infrastructure included a modern email system, a legacy messaging platform, and a voice recording system with its own proprietary format. Building the ingestion pipeline that normalised communication metadata from all three sources into a format the policy compliance agent could evaluate took six weeks, longer than building the agent itself.

The operational architecture

┌──────────────────────────────────────────────────┐
│              Event Sources                        │
│  Core banking │ Payments │ CRM │ Comms │ Trading │
└───────────────────────┬──────────────────────────┘
                        │ (Event-driven)
                        ▼
┌──────────────────────────────────────────────────┐
│           Stream Processing Layer                 │
│  (Kafka / event bus - normalisation, routing)    │
└───────────────────────┬──────────────────────────┘
                        │
         ┌──────────────┼──────────────┐
         ▼              ▼              ▼
┌──────────────┐ ┌────────────┐ ┌────────────────┐
│ Deterministic│ │ AI-Assisted│ │ Policy         │
│ Rules Engine │ │ Evaluator  │ │ Monitor        │
│ (85% volume) │ │ (15% vol)  │ │ (async)        │
└──────┬───────┘ └─────┬──────┘ └───────┬────────┘
       │               │               │
       └───────────────┼───────────────┘
                       ▼
┌──────────────────────────────────────────────────┐
│           Audit Trail Engine                      │
│  (Append-only │ Immutable │ 7-10yr retention)    │
└───────────────────────┬──────────────────────────┘
                        │
         ┌──────────────┼──────────────┐
         ▼              ▼              ▼
┌──────────────┐ ┌────────────┐ ┌────────────────┐
│ Alert Queue  │ │ Dashboard  │ │ Audit Readiness │
│ (compliance  │ │ (real-time │ │ Agent (batch    │
│  team)       │ │  metrics)  │ │  assembly)      │
└──────────────┘ └────────────┘ └────────────────┘

The stream processing layer is the foundational infrastructure investment. We use Kafka for event ingestion because the throughput requirements (200,000+ events daily with sub-minute processing latency) exceed what REST-based architectures handle gracefully. Each source system produces events to Kafka topics. The normalisation layer transforms source-specific event formats into the common evaluation schema.

The deterministic and AI-assisted evaluation paths are separate consumers from the same Kafka topics. The routing decision, which transactions need AI evaluation versus deterministic-only, is made by a lightweight classifier at the stream processing layer based on transaction characteristics (amount, type, counterparty risk level, customer risk profile).

What this costs to build and run

Development timeline: approximately five months for the core system (transaction monitoring, audit trail, basic regulatory change monitoring). An additional two months for policy compliance monitoring and the audit readiness agent. Total: seven months from kickoff to full production deployment.

Infrastructure costs: approximately $4,000 to $7,000 per month for a mid-size deployment. This covers the Kafka cluster, the inference compute for the AI tier, the PostgreSQL hot tier, and the S3 cold storage. The LLM inference costs are the largest variable component, they scale with the volume of transactions routed to the AI tier.

The cost comparison against manual monitoring: a twelve-person compliance team doing sample-based review costs roughly $1.2 to $1.8 million annually in fully loaded compensation. The agent-based system costs roughly $250,000 to build and $60,000 to $85,000 annually to operate. The system monitors 100 percent of transactions. The manual team monitored 5 percent. The math isn't close, and it gets more favourable as transaction volume grows because the system's cost scales sub-linearly while the manual team's cost scales linearly.

For financial institutions ready to build compliance monitoring that evaluates every transaction against every applicable rule with complete audit trail documentation, the AI agent development partner practice at Dextra Labs covers the full stack, from stream processing architecture through deterministic rule engines, AI-assisted evaluation pipelines, audit trail implementation, and the regulatory change monitoring that keeps the rule set current as regulations evolve.

The compliance monitoring problem is fundamentally an engineering problem. The AI components are important but bounded, they handle the 15 percent of evaluations that require interpretation. The other 85 percent is deterministic rules applied at streaming scale with complete auditability. Building for compliance means building for both, and knowing which evaluation type applies to which rule.

Published by Dextra Labs, AI Consulting and Enterprise Agent Development

The Shift from AI Insights to AI Actions in Finance

Dextra Labs — Wed, 23 Sep 2026 07:47:05 +0000

There's a line in finance technology that most teams don't realise they've been standing on one side of for the past decade.

On one side: AI that tells you things. A model that predicts which invoices will be paid late. A dashboard that flags anomalous transactions. A forecast that estimates next quarter's revenue. A risk score that classifies a loan application.

On the other side: AI that does things. An agent that processes the invoice, chases the payment, and reconciles the outcome. A system that detects the anomalous transaction, investigates it, assembles the evidence, and routes a case to the investigator with full context. An underwriting pipeline that reads the application, extracts the financials, calculates the ratios, checks compliance, and produces a recommendation with a documented reasoning chain.

The first category, traditional AI in finance, has been in production for years. It works. It's valuable. It gives finance teams better information to act on.

The second category, agentic AI, is what's changing the operational economics of finance right now. It doesn't give teams better information. It handles the work that teams used to do with that information.

The distinction matters architecturally because the two categories are built differently. And it matters operationally because AI agents across finance operations are delivering ROI measured in headcount reallocation and cycle time compression, not in "better dashboards."

This article walks through the architectural shift from insights to actions, what changes in the system design, what new components are required, and what the code looks like when you move from a model that scores to an agent that executes.

What traditional AI in finance actually looks like

Traditional AI in finance is predominantly predictive and classificatory. The model receives structured input, produces a score or a classification, and hands it to a human who decides what to do.

A credit scoring model is the canonical example:

# Traditional AI: predict, score, hand to human
class CreditScorer:
    def __init__(self, model):
        self.model = model

    def score(self, application: dict) -> CreditScore:
        features = self.extract_features(application)
        probability = self.model.predict_proba(features)

        return CreditScore(
            applicant_id=application["id"],
            score=probability[1],  # P(default)
            risk_tier=self.classify_tier(probability[1]),
            timestamp=datetime.utcnow()
        )

    def extract_features(self, application: dict) -> np.array:
        return np.array([
            application["debt_to_income"],
            application["credit_utilization"],
            application["payment_history_months"],
            application["employment_years"],
            # ... 30+ features manually extracted upstream
        ])

The model does one thing well: given a set of pre-extracted features, it produces a probability of default. That probability is valuable. An underwriter who has it makes better decisions than one who doesn't.

But look at what the model doesn't do. It doesn't extract the features, someone upstream manually pulled the debt-to-income ratio from bank statements, calculated credit utilisation from bureau data, and assembled the feature vector. It doesn't check compliance, someone downstream verifies the application against regulatory requirements. It doesn't produce a recommendation, someone interprets the score in the context of credit policy. It doesn't document its reasoning in a way a regulator can audit, the score is a number without an explanation.

The model is one step in a multi-step workflow where humans perform every other step. The model made that one step better. It didn't change the workflow.

A fraud detection model follows the same pattern:

# Traditional AI: flag, score, queue for human review
class TransactionFraudModel:
    def __init__(self, model, threshold=0.7):
        self.model = model
        self.threshold = threshold

    def evaluate(self, transaction: dict) -> FraudAlert | None:
        features = self.extract_features(transaction)
        fraud_probability = self.model.predict_proba(features)[1]

        if fraud_probability > self.threshold:
            return FraudAlert(
                transaction_id=transaction["id"],
                score=fraud_probability,
                alert_type="model_triggered",
                timestamp=datetime.utcnow()
            )
        return None

The model evaluates one transaction against one set of features at one point in time. It doesn't maintain a behavioural model across months of activity. It doesn't map relationships between accounts. It doesn't investigate the alert, an analyst does that. The model produces the flag. Humans do everything around it.

This is the insight paradigm. AI makes the information better. Humans do the work.

What the shift to actions looks like architecturally

The agentic paradigm replaces the single-step prediction with a multi-step execution loop. The agent doesn't just score, it reasons, plans, uses tools, handles exceptions, and produces a complete outcome.

The architectural difference is the reasoning loop. Traditional AI is function call: input → output. Agentic AI is a loop: observe → think → act → observe → think → act, continuing until the goal is achieved or the agent recognises it needs to escalate.

Here's the same underwriting workflow as an agent:

# Agentic AI: observe, reason, act, repeat until goal is met
class UnderwritingAgent:
    def __init__(self, llm, tools, compliance_rules, confidence_threshold=0.85):
        self.llm = llm
        self.tools = tools
        self.rules = compliance_rules
        self.threshold = confidence_threshold
        self.audit_log = []

    async def process_application(self, application_id: str) -> UnderwritingResult:
        # Step 1: Gather and extract documents
        docs = await self.tools.fetch_documents(application_id)
        extracted = await self.extract_all_documents(docs)

        # Step 2: Verify completeness
        missing = self.check_completeness(extracted, required_docs=["bank_statements",
            "tax_returns", "business_registration", "financial_statement"])

        if missing:
            await self.tools.request_documents(application_id, missing)
            self.audit_log.append(AuditEntry(
                step="document_collection",
                action="requested_missing_documents",
                details=missing,
                timestamp=datetime.utcnow()
            ))
            return UnderwritingResult(status="pending_documents", missing=missing)

        # Step 3: Calculate credit metrics
        metrics = self.calculate_metrics(extracted)

        # Step 4: Run compliance checks
        compliance = self.run_compliance_checks(extracted, metrics)

        # Step 5: Produce risk assessment
        assessment = await self.assess_risk(extracted, metrics, compliance)

        # Step 6: Route based on confidence
        if assessment.confidence >= self.threshold and compliance.all_passed:
            return UnderwritingResult(
                status="auto_recommended",
                risk_tier=assessment.risk_tier,
                metrics=metrics,
                compliance=compliance,
                reasoning=assessment.reasoning,
                audit_trail=self.audit_log
            )
        else:
            return UnderwritingResult(
                status="escalated_to_human",
                risk_tier=assessment.risk_tier,
                metrics=metrics,
                compliance=compliance,
                reasoning=assessment.reasoning,
                escalation_reason=self.get_escalation_reason(assessment, compliance),
                audit_trail=self.audit_log
            )

    async def extract_all_documents(self, docs: list[Document]) -> ExtractedData:
        """Extract data from each document using semantic understanding"""
        extracted = ExtractedData()

        for doc in docs:
            result = await self.tools.extract_document(
                document=doc,
                required_fields=self.get_required_fields(doc.type)
            )

            # Flag low-confidence extractions for human verification
            for field, value in result.fields.items():
                if value.confidence < 0.88:
                    result.flags.append(f"Low confidence on {field}: {value.confidence}")

            extracted.add(doc.type, result)
            self.audit_log.append(AuditEntry(
                step="document_extraction",
                document_type=doc.type,
                fields_extracted=len(result.fields),
                flags=result.flags,
                timestamp=datetime.utcnow()
            ))

        return extracted

    def calculate_metrics(self, data: ExtractedData) -> CreditMetrics:
        """Deterministic calculations, no AI needed"""
        return CreditMetrics(
            dscr=data.net_operating_income / data.total_debt_service,
            dti=data.total_monthly_debt / data.gross_monthly_income,
            ltv=data.loan_amount / data.collateral_value,
            current_ratio=data.current_assets / data.current_liabilities,
            cash_flow_trend=self.calculate_trend(data.monthly_cash_flows)
        )

    def run_compliance_checks(self, data: ExtractedData, 
                               metrics: CreditMetrics) -> ComplianceResult:
        """Rules-based compliance - deterministic, auditable"""
        results = []
        for rule in self.rules.get_applicable(data.loan_type):
            passed = rule.evaluate(data, metrics)
            results.append(ComplianceCheck(
                rule_id=rule.id,
                rule_description=rule.description,
                passed=passed,
                evidence=rule.get_evidence(data, metrics),
                timestamp=datetime.utcnow()
            ))
            self.audit_log.append(AuditEntry(
                step="compliance_check",
                rule_id=rule.id,
                passed=passed,
                timestamp=datetime.utcnow()
            ))

        return ComplianceResult(checks=results, all_passed=all(r.passed for r in results))

The code makes the architectural shift visible. The traditional model was a single function call: features in, score out. The agent is a multi-step workflow: gather documents, extract data, verify completeness, calculate metrics, check compliance, assess risk, and route based on confidence, with an audit trail documenting every step.

The five capabilities that separate agents from models

The underwriting agent code above demonstrates five capabilities that traditional models don't have. These five capabilities are what define the shift from insights to actions.

Tool use. The agent calls external systems, document storage, extraction services, the ERP, the compliance database. Traditional models receive pre-processed input. Agents fetch and process their own input by interacting with the systems where the data lives.

# Tool use: agent interacts with external systems
class AgentTools:
    async def fetch_documents(self, app_id: str) -> list[Document]:
        """Pull documents from the origination system"""
        return await self.origination_client.get_documents(app_id)

    async def extract_document(self, document: Document, 
                                required_fields: list) -> ExtractionResult:
        """Semantic extraction, understands content, not positions"""
        return await self.extraction_service.extract(
            document=document,
            fields=required_fields,
            return_confidence=True
        )

    async def request_documents(self, app_id: str, missing: list):
        """Send targeted document request to borrower"""
        await self.communication_service.send_document_request(
            application_id=app_id,
            missing_documents=missing,
            template="targeted_request"  # Specific, not generic
        )

State management

The agent maintains state across the workflow, what documents have been received, what data has been extracted, what compliance checks have passed, what the risk assessment concluded. Traditional models are stateless: same input, same output, no memory of what happened before.

Confidence-based routing

The agent knows when it's confident enough to recommend and when it should escalate. The confidence threshold is a design parameter that determines the system's autonomy boundary. Traditional models produce scores that humans interpret. Agents produce scores and act on them according to defined rules.

Exception handling

When the agent encounters something unexpected, a missing document, a low-confidence extraction, a compliance check that fails, it doesn't stop. It classifies the exception, determines the appropriate response, and either handles it within its authority or escalates with context. Traditional models have no concept of exceptions. They produce output regardless of input quality.

Audit trail generation

Every step the agent takes, every tool call, every extraction, every calculation, every routing decision, is logged with timestamps, inputs, and reasoning. The agentic AI for finance and accounting architecture treats the audit trail as a first-class output, not an afterthought. In regulated environments, the audit trail is often more valuable than the processing itself because it's what regulators actually examine.

Why the shift is happening now

Three technical developments converged to make the action paradigm viable.

Foundation models with tool-use capability. LLMs that can reason about when to call a tool, what inputs to provide, and how to interpret the results are the core enabler. Two years ago, getting a model to reliably call the right tool with the right parameters in a multi-step workflow required extensive prompt engineering and fragile orchestration. In 2026, tool calling is a native capability with structured outputs that integration code can rely on.

Infrastructure for agent orchestration. Frameworks for managing agent state, coordinating multi-step workflows, handling retries and errors, and maintaining audit trails have matured from experimental libraries to production-grade infrastructure. The orchestration layer that was custom-built for early deployments is now available as reusable architecture.

Cost reduction at inference scale. Processing 200,000 transactions daily through an LLM was economically impractical two years ago. The combination of tiered models (using expensive models only where judgment is required and cheap models or deterministic rules for everything else), prompt caching, and inference optimisation has reduced the per-transaction cost to levels where production-scale agent deployment is financially viable.

The hybrid architecture that actually works

The practical agent architecture in finance isn't "AI does everything." It's a deliberate split between what requires AI and what doesn't.

# The hybrid: deterministic where possible, AI where necessary
class HybridFinanceAgent:
    def __init__(self, rules_engine, ai_evaluator, tools):
        self.rules = rules_engine      # Fast, deterministic, auditable
        self.ai = ai_evaluator         # Interpretive, contextual, slower
        self.tools = tools

    async def process(self, event: FinanceEvent) -> ProcessingResult:
        # Deterministic first: apply all clear rules
        rule_results = self.rules.evaluate(event)

        # If rules are conclusive, no AI needed
        if rule_results.is_conclusive():
            return ProcessingResult(
                decision=rule_results.decision,
                evaluation_type="deterministic",
                reasoning=rule_results.evidence,
                confidence=1.0  # Rules are binary
            )

        # AI for the ambiguous remainder
        context = await self.tools.assemble_context(event)
        ai_result = await self.ai.evaluate(
            event=event,
            context=context,
            applicable_rules=rule_results.inconclusive_rules
        )

        return ProcessingResult(
            decision=ai_result.classification,
            evaluation_type="ai_assisted",
            reasoning=ai_result.reasoning,
            confidence=ai_result.confidence,
            model_version=self.ai.model_version,
            context_hash=hash(str(context))
        )

This hybrid pattern appears in every production finance agent we've built. The deterministic engine handles 75 to 85 percent of evaluations, the clear-cut cases where rules produce binary answers. The AI engine handles the remaining 15 to 25 percent, the cases where interpretation, context, and judgment are genuinely required.

The split matters for three reasons. Cost, deterministic evaluations are essentially free compared to LLM inference. Speed, rules execute in milliseconds versus seconds for AI evaluation. Auditability, deterministic evaluations produce provably consistent results that regulators find easier to examine than probabilistic AI assessments.

The agents that try to run everything through AI are more expensive, slower, and harder to audit than hybrid architectures that reserve AI for the work that actually needs it. This echoes what we've seen across every domain: the best agent systems use less AI than you'd expect, applied precisely where it creates value.

The operational results

The shift from insights to actions produces measurable operational changes that the insight paradigm couldn't deliver.

Cycle time compression. When the agent handles document collection, extraction, calculation, and compliance, instead of just scoring, the end-to-end processing time drops by 80 to 90 percent. An underwriting workflow that took 11 days drops to 31 hours. An AP invoice that took 11 days to approve processes in under 3 days. The time compression comes from eliminating the human steps between the AI steps, not from making the AI step faster.

Volume capacity multiplication. When 70 to 78 percent of transactions process without human intervention, the team's capacity for judgment work multiplies by 3 to 4x without adding headcount. One underwriting team went from 14 people processing all cases to 3 people handling a higher volume of complex cases.

Error rate reduction. Agents that apply compliance checks and matching logic with deterministic consistency produce 70 to 85 percent fewer errors than human teams performing the same checks at volume. The consistency isn't AI, it's the deterministic engine running the same rules every time without fatigue or attention drift.

Audit trail completeness. Traditional workflows produce audit trails assembled after the fact, someone reconstructing what happened from email threads and system logs. Agent workflows produce audit trails generated during the processing, every step documented as it occurs. The shift from retrospective to contemporaneous documentation is what changes compliance posture.

Where the shift is heading

The current generation of finance agents handles single-domain workflows, underwriting, AP processing, compliance monitoring, fraud detection. Each agent operates within one bounded domain with its own tools, rules, and escalation logic.

The next evolution is cross-domain agent orchestration, systems where a lending agent's credit assessment informs a fraud agent's risk scoring, where a compliance agent's regulatory change detection triggers a policy agent's rule update, where a customer operations agent's case resolution feeds back into a risk model's training data.

This cross-domain orchestration is where the compound value lives. Individual domain agents deliver linear improvements. Connected agents across domains deliver compounding improvements because intelligence flows between them.

That orchestration layer is the engineering challenge worth watching and building toward, in 2026.

For finance teams ready to make the shift from AI insights to AI actions, the custom AI agent development company practice at Dextra Labs builds the hybrid architectures described in this article, deterministic engines for the clear-cut evaluations, AI for the interpretive work, and the orchestration layer that connects them into workflows that execute rather than advise. Whether the starting point is underwriting, AP, compliance, or fraud detection, the architectural pattern is consistent and the engineering path is proven.

The insight era gave finance teams better information. The action era gives them back their time.

Published by Dextra Labs - AI Consulting and Enterprise Agent Development

Why SMBs Choose Custom AI Agent Development Over Off-the-Shelf Platforms

Dextra Labs — Tue, 22 Sep 2026 05:26:59 +0000

There is no shortage of AI agent platforms in 2026. A business can spin up an agent quickly, connect a few apps, and automate a basic workflow without building an entire AI stack from the ground up.

The catch is that a successful first demo is not the same thing as a production-ready system. What works in a five-minute walkthrough often starts to strain the moment real business complexity shows up.

An SMB usually discovers, a little further in, that its workflow actually depends on proprietary business rules, internal databases, multiple APIs, custom approval logic, customer-specific context, human escalation, and permissions with auditability. A generic agent rarely accounts for all of that.

The question is not whether an off-the-shelf AI agent can automate something. It is whether it can automate the way your business actually works.

Off-the-Shelf AI Agents vs. Custom AI Agents: What's the Difference?

First, a misconception worth clearing up. Custom does not mean building an AI model or an agent framework from zero.

In 2026, custom AI agent development usually means combining existing models, agent SDKs, databases, APIs, and orchestration frameworks into a system designed around one company's workflow. The engineering work is increasingly about integration, guardrails, and evaluation rather than reinventing the underlying AI infrastructure.

The trade-off comes down to one line. Off-the-shelf platforms optimize for speed to first deployment. Custom agents optimize for fit with the workflow.

Why SMBs Are Outgrowing "Plug-and-Play" AI

This is less about the shortcomings of any single platform and more about a natural progression that many SMBs go through as their needs mature.

1. The workflow isn't standard

An accounting firm, a logistics company, and a SaaS business may all say they want a "customer support agent," but the actual workflows behind that phrase are completely different.

2. Existing systems don't always fit the platform

SMBs often run a mix of CRM, ERP, spreadsheets, internal databases, proprietary applications, and SaaS tools, and the agent has to work coherently across all of them.

3. Business logic becomes more important

Simple instructions eventually turn into real conditional chains, where if something happens the agent checks one thing, compares another, requests an approval, updates a record, and notifies someone.

4. AI needs business context

Generic knowledge is not enough once the agent has to understand internal policies, customer history, or proprietary processes.

5. The agent becomes part of the product

Once customers or employees rely on it, the company needs far more control over how it behaves, how it fails, and how it evolves.

The Five Reasons SMBs Choose Custom AI Agent Development

This is the heart of the matter, so each reason is worth looking at on its own terms.

1. Custom Workflows, Not Generic Automation

Off-the-shelf platforms generally work best when the workflow fits the capabilities they have already designed. Step outside those capabilities and you start bending your process to suit the tool.

Custom agents let developers model the actual process instead, moving through trigger, understanding, retrieval, decision, action, verification, and escalation in whatever shape the business needs. The agent follows business-specific logic rather than forcing the business to redesign itself around the platform.

2. Deep Integration With Existing Systems

A useful SMB agent often has to move through several systems in a single workflow. It might read from the CRM, pull records from a customer database, check the ERP or inventory system, call an internal API, consult a knowledge base, and finally update a notification or ticketing system.

The value here is not the raw number of integrations. It is whether the agent can use those systems coherently during one continuous workflow, rather than treating each as a disconnected lookup.

3. Proprietary Data Becomes an Advantage

Generic AI knows general information. That is useful, but it is also available to everyone else.

A custom agent can reason over the things that are specific to your company:

SOPs and product documentation
Customer history and contracts
Internal policies and operational data

This is exactly where RAG, structured data retrieval, and context engineering become important. The competitive advantage often is not the model. It is the context the model can reliably use.

4. Greater Control Over Permissions and Actions

Consider an agent that can read customer data, issue refunds, modify account information, and send emails. Should it really have unrestricted access to all four? Almost certainly not.

A custom architecture lets developers define the boundaries precisely:

Which tools the agent can access
Which actions require approval
Which users can trigger actions
Which data the agent can retrieve
What gets logged

This matters more and more as agents move from answering questions to taking actions, which is why identity, access control, and auditability sit at the center of serious agent architecture.

5. The Agent Can Evolve With the Business

An SMB's processes rarely stay still. A new CRM, a new pricing model, a new approval process, a new product line, or a new compliance requirement can all land within a single year.

A custom agent can be engineered around an architecture that evolves with those changes, rather than waiting on a platform's roadmap to catch up to where the business already is.

The Hidden Cost of "Cheap" AI Platforms

It is tempting to treat the monthly subscription as the price of the platform. In practice, the real cost is spread across several areas that do not appear on the pricing page.

A platform can look cheaper at the start and still become expensive once every additional workflow demands workarounds, premium connectors, or platform-specific logic.

To be fair, custom development is not automatically cheaper either. It carries real upfront engineering cost, and pretending otherwise would be dishonest. The point is not that custom always wins on price, but that the true comparison is total cost over time, not the headline subscription.

When Off-the-Shelf Platforms Actually Make More Sense

Custom is not always the answer, and it would be misleading to suggest otherwise. Off-the-shelf platforms are a genuinely sensible choice in plenty of situations, including when the workflow is simple, the integrations are already supported, the risk is low, the business logic is straightforward, speed matters more than customization, the agent is mainly internal, and the process is unlikely to change much.

The right question is not "Build or buy?" It is "Where does the workflow stop fitting the product?"

## A Better Approach: Start With One Workflow

Rather than debating the whole strategy at once, the most productive move is to prove the idea on a single workflow. Here is a practical six-step way to do that.

1. Pick one workflow:

Do not start with "let's build an AI employee." Start with something concrete, like "let's automate invoice reconciliation."

2. Map the current process:

Document the trigger, the inputs, the decisions, the actions, the output, and the exceptions, in that order.

3. Identify system dependencies:

List every API, database, CRM, ERP, knowledge source, and human approval the workflow touches.

4. Define agent permissions:

Decide exactly what the agent can read, decide, write, and execute, and where the limits sit.

5. Build evaluation scenarios:

Test normal cases, missing information, incorrect inputs, edge cases, tool failures, and ambiguous requests.

6. Measure the outcome:

Track task completion, error rate, human escalation, latency, and cost per task.

Done this way, you learn whether custom development is worth it in one workflow before committing to it across the business.

What a Custom SMB AI Agent Stack Can Look Like

It helps to picture the stack as a path a request travels through. A user or business event reaches the agent interface, which hands off to an orchestration layer, which calls an LLM or reasoning model, draws on a context and retrieval layer, invokes tools and APIs, connects to the underlying business systems, passes through validation and human approval, and finally produces an action.

In practice, that stack might combine model providers, agent frameworks, RAG and vector search, structured databases, REST APIs, MCP and tool interfaces, authentication, observability, and evaluation pipelines. None of these has to be built from scratch.

The developer takeaway is straightforward. Custom development is less about building every component yourself and more about choosing the right components and composing them around the workflow.

The Production Problems You Don't See in the Demo

The gap between a prototype and a production system is where most of the real work lives, and it is easy to underestimate from a polished demo.

A two-hour agent demo can prove that something is possible. It cannot prove that the system is reliable enough to run a business workflow unattended, and that distinction is the whole game when moving a custom agent from prototype into production.

Custom Doesn't Mean "Build Everything From Scratch"

The myth: custom AI means training your own foundation model and maintaining an enormous AI infrastructure stack.

The reality: a custom agent can lean on proven components, combining open-source frameworks, commercial models, APIs, vector databases, cloud infrastructure, and existing enterprise systems.

The customization does not happen at the model layer. It happens in workflow design, tool selection, context management, business rules, permissions, evaluation, user experience, and integration architecture. In other words, the modern approach to custom AI models vs off-the-shelf is largely about composition, not reinventing foundational AI technology.

A Practical Build-vs-Buy Checklist for SMBs

Before committing either way, it helps to answer five honest questions.

1. Does the workflow differentiate our business? If yes, customization may matter.

2. Does the agent need deep access to internal systems? If yes, integration architecture becomes critical.

3. What happens if the agent makes a mistake? Higher-impact actions require stronger controls.

4. Will the workflow change frequently? If yes, flexibility becomes more valuable.

5. Do we need ownership and control? Consider data, infrastructure, model choice, observability, and vendor dependency.

From there, a simple decision path tends to emerge. A standard workflow with low risk and supported integrations points toward starting with a platform. A custom workflow with deep integrations and meaningful business impact points toward custom development. And a mix, where some workflows are standard and others are differentiated, points toward a hybrid approach.

The Emerging SMB Model: Buy the Commodity, Build the Differentiator

The most balanced model in 2026 is not a binary choice at all. It is a deliberate split between what to buy and what to build.

SMBs do not have to choose between platforms and custom development wholesale. A practical architecture uses off-the-shelf tools for commodity automation while reserving custom engineering for the workflows that genuinely create differentiation. That is a more realistic stance than treating custom development as a universal replacement for platforms.

Final Takeaway: The Best Agent Is the One That Fits the Workflow

Off-the-shelf AI agent platforms have lowered the barrier to experimentation, and that is a real gain. SMBs can now automate tasks that used to require substantial engineering effort.

As a workflow becomes more valuable, complex, or differentiated, though, the limits of a generic platform tend to become more visible. That is usually the moment the conversation shifts toward custom work, and a capable AI agent development company can help a business decide which workflows are worth owning and which are fine to rent.

Custom AI agent development gives businesses greater control over how the agent reasons, what data it sees, which tools it can use, what actions it can take, and how failures are handled. The goal is not to build AI because custom sounds more impressive. The goal is to build when the workflow itself is worth owning.

Buy the commodity. Build the workflow that makes your business different.

Voice AI vs Chat AI: How to Choose the Right Customer Support Channel

Dextra Labs — Mon, 21 Sep 2026 04:42:47 +0000

Choosing an AI support channel is not simply a matter of deciding whether your customers would rather talk or type. That framing feels intuitive, but it skips the question that actually determines success, which is what the customer is trying to accomplish in the first place.

Voice and chat each have real strengths, and they do not overlap as much as they seem to. Voice is genuinely useful for urgency, complexity, emotion, and hands-free interactions, while chat is better for speed, asynchronous support, sharing links and screenshots, and absorbing high volumes of routine queries. The right choice follows the customer journey rather than the novelty of the technology.

The market reflects this split rather than a winner. Voice AI now handles around 19% of inbound contact-center volume in 2026, up from just 6% in 2024 according to Forrester Wave research, yet chat remains the workhorse for high-volume digital support. The best AI customer support channel is the one that matches the task, the customer context, and the level of action required, and the framework below will help you find it.

Voice AI vs Chat AI: What Is the Difference?

Before comparing the two, it helps to define each one clearly, since both get lumped together under "conversational AI" even though they behave quite differently in practice.

What Is Voice AI for Customer Support?

Voice AI uses speech recognition, language understanding, reasoning, and text-to-speech to hold a spoken conversation with a customer. Its common capabilities include:

Answering inbound calls
Identifying customer intent
Verifying customer information
Retrieving account details
Updating records
Scheduling appointments
Routing complex cases to human agents

Modern voice AI is far more than an IVR menu, but it still lives or dies on strong latency control, interruption handling, and reliable fallback logic, because a spoken conversation punishes hesitation far more than a text one does.

What Is Chat AI for Customer Service?

Chat AI operates through websites, mobile apps, messaging platforms, and customer portals, meeting customers in the digital spaces they already use. Its typical capabilities include:

Answering FAQs
Searching knowledge bases
Tracking orders or tickets
Collecting structured information
Sharing links and documents
Creating or updating support tickets
Escalating conversations to human agents

Voice AI vs Chat AI: What is the Core Difference Between Them?

The cleanest way to see the contrast is side by side:

Start With the Customer Journey, Not the AI Channel

The most reliable way to choose badly is to pick a channel first and fit the workflow to it afterward. Map the support workflow first, and the right channel tends to reveal itself.

1. Identify the Type of Customer Request

Start by sorting your support requests into categories, because different types behave very differently across channels:

Simple information requests
Transactional requests
Multi-step troubleshooting
Sensitive or high-risk issues
Emotionally charged complaints
Requests requiring human judgment

2. Map the Systems the Agent Must Access

Then get honest about what the agent has to reach in order to actually resolve the request, rather than just talk about it. Ask:

Does the agent need access to a CRM?
Can it retrieve order or account information?
Does it need to create tickets?
Must it trigger refunds, replacements, or cancellations?
Are identity verification and permissions required?
What happens when an API fails?

Example: Order Delivery Support

The same workflow can suit either channel depending on the customer's situation.

Chat AI may be the better fit when:

Customers simply want to check an order status
The agent can hand over a tracking link
Customers need to upload an image or share written details
The interaction can happen asynchronously

Voice AI may be the better fit when:

A delivery is urgent
The customer is frustrated or confused
Several details must be clarified conversationally
The customer is unable or unwilling to type

The takeaway is that the decision is not "voice or chat?" It is "which channel helps this customer complete this task with the least friction?"

When Voice AI Is the Better Customer Support Channel

There are clear situations where voice creates more value than chat, and they usually share a common thread of urgency or human nuance. This is where AI agents for customer service earn their place on the phone rather than the screen.

1. High-Urgency Support

Voice shines when the customer needs help right now:

Service outages
Travel disruptions
Medical appointment scheduling
Payment or account access issues
Time-sensitive delivery problems

2. Complex or Multi-Step Conversations

Voice reduces the friction of entering long explanations, which matters most when customers need to describe a problem in their own words rather than squeezing it into a text box.

3. Emotionally Charged Interactions

Customers often prefer speaking when they are frustrated, anxious, or dealing with something serious, and a well-built voice agent can acknowledge that emotion and route the conversation to a human when the moment calls for it.

4. Hands-Free or Accessibility-Driven Use Cases

Voice is valuable when customers are driving, working with their hands, have limited typing ability, or interact through a phone-first support environment where calling is simply the natural choice.

5. Important Voice AI Limitations

Voice is not a free win, and it carries real constraints worth planning around:

Speech recognition can fail with accents, background noise, or poor connections
Long pauses and latency make conversations feel unnatural
Customers may repeat themselves if the agent loses context
Sensitive actions require strong verification and confirmation
Voice interactions are harder to scan or review than text transcripts

When Chat AI Is the Better Customer Support Channel

Chat is the right first channel far more often than the excitement around voice suggests, especially for high-volume digital support. The economics back this up, since chat resolutions average roughly $0.41 each against about $1.18 for voice AI and $7.40 for a human agent.

1. High-Volume, Repeatable Questions

Chat excels at the steady stream of predictable queries:
Password reset instructions

Product availability
Shipping policies
Billing FAQs
Return and warranty information
Basic troubleshooting

2. Support That Requires Links, Images, or Documents

Chat is often more effective when customers need to work with visual or written material, such as when they need to:

Open a help article
Follow step-by-step instructions
Upload a screenshot
Share an order number
Review a policy
Complete a form

3. Asynchronous Customer Support

Chat lets a customer leave a message, return later, and review the conversation without repeating every detail, which fits the way people actually manage their time.

4. Lower-Friction Self-Service

Chat can be embedded directly into a website, app, or portal, letting customers start support without dialing a number or waiting in a queue, which removes a real barrier to getting help.

5. Important Chat AI Limitations

Chat has its own failure modes, and pretending otherwise leads to a frustrating deployment:

Customers may abandon conversations when responses are slow or generic
Text-only interaction can be frustrating for genuinely complex problems
Poorly designed chatbots create repetitive loops
Chat agents still need reliable integrations and human escalation
A chat interface does not automatically make the underlying agent intelligent

Voice AI vs Chat AI: Compare the Total Cost, Not Just the Tool Price

The price of the AI model is only a fraction of what each channel actually costs to run, and a fair voice agent vs chatbot comparison has to weigh the full stack rather than the tool price alone. Each channel carries a different set of expenses underneath the interface.

Voice AI Cost Factors

Telephony and carrier fees
Inbound and outbound call minutes
Speech-to-text processing
Text-to-speech generation
Real-time infrastructure
Call recording and transcription
Human transfer costs
Monitoring and quality assurance

Chat AI Cost Factors

Platform subscription
Message or conversation volume
Model and token usage
Knowledge-base indexing
Premium integrations
Agent seats and escalation workflows
Analytics and conversation storage
Support and customization fees

The Cost per Resolved Issue Matters More

Rather than comparing sticker prices, measure what it actually costs to

solve a customer's problem:

Cost per resolved interaction
Average handling time
Escalation rate
Repeat contact rate
Customer satisfaction
Revenue or retention impact

A cheaper interaction is not automatically the better one, because a low per-message cost means little if it generates repeat contacts or quietly pushes every hard case to a human agent.

Integration and Workflow Depth Matter More Than the Interface

Voice and chat are ultimately just customer-facing interfaces, and the real value of an agent comes from what it can do behind them. An agent that sounds wonderful but cannot act is still a dead end for the customer.

That value depends on integration with the systems where the work actually happens:

CRM systems
Help desks
Order management platforms
Billing and payment systems
Scheduling tools
Identity and authentication systems
Internal knowledge bases
Communication platforms

Read-Only vs Action-Oriented Agents

There is a meaningful difference between an agent that can only retrieve information and one that can actually change something.

Read-only examples:

Checking order status
Explaining a policy
Retrieving account information

Action-oriented examples:

Rescheduling an appointment
Creating a support ticket
Initiating a replacement
Updating customer information
Escalating based on risk or sentiment

Permissions and Guardrails

An agent should never receive unrestricted access to every system, no matter how capable it is, which is why an experienced custom AI agent development company designs boundaries alongside capability:

Role-based permissions
Identity verification
Approval requirements for high-risk actions
Audit logs
Tool-level access controls
Human confirmation for irreversible actions

Human Handoff Is a Requirement, Not a Backup Plan

Both voice AI and chat AI need a clearly designed escalation path from the start, because the handoff is where trust is either preserved or lost. Treating it as an afterthought shows up in exactly your worst customer moments.

When Should the AI Escalate?

Some situations should trigger a handoff almost every time:

The customer explicitly requests a human
The agent fails repeatedly
The issue involves a vulnerable customer
A refund, cancellation, or financial action is high-risk
The customer expresses severe frustration
Required information is missing
The agent detects its own uncertainty

What a Good Handoff Includes

When the agent escalates, the human should inherit the full picture rather than a blank slate:

The conversation transcript or call summary
Customer identity and account context
Actions already attempted
Relevant system errors
The reason for escalation
A recommended next step

Avoid Repeating the Customer's Story

A poor handoff forces the customer to start over, which is one of the fastest ways to turn a recoverable situation into a lost one. A well-designed handoff preserves context and makes the transition feel like one continuous conversation rather than a cold restart.

Security, Privacy, and Reliability Considerations

Each channel carries its own risks, and they are different enough that a single security checklist will miss things. It helps to look at them separately and then at what they share.

1. Voice AI considerations:

Call recording consent
Voice data retention
Caller authentication
Spoofing and impersonation risks
Background noise and misrecognition
Secure transfer to human agents

Chat AI considerations:

Sensitive information sitting in chat logs
Prompt injection through uploaded content
Unauthorized account access
Data retention and deletion
Exposure of internal knowledge
Unsafe links or generated instructions

Shared requirements: both channels should support encryption in transit and at rest, access controls, auditability, data minimization, monitoring and alerting, defined retention policies, tested fallback procedures, and clear ownership of customer data.

Security here is not a checkbox exercise, though. The controls you actually need depend on your industry, geography, the data involved, and the actions the agent is allowed to perform, so treat this as a design input rather than a form to sign at the end.

Should You Use Voice AI, Chat AI, or Both?

For many businesses the honest answer is both, arranged so that each channel does what it is best at. An omnichannel approach is less about offering more channels and more about placing them intelligently.

Use Chat as the First Layer When

Most requests are simple and repeatable
Customers need links, documents, or screenshots
The business receives high digital traffic
Customers prefer asynchronous support
The organization wants to deflect routine tickets

Use Voice as the First Layer When

Customers primarily contact support by phone
Issues are frequently urgent or complex
The service involves emotional or sensitive situations
Customers need conversational clarification
The support environment is hands-free or phone-first

Use Both When the Journey Has Multiple Stages

A layered journey often looks like this:

The customer starts in chat.
Chat AI identifies the issue and gathers basic information.
The customer requests a call, or the system detects complexity.
Voice AI continues with the existing context intact.
A human agent takes over if the issue requires real judgment.

The design principle that matters here is continuity across channels, not simply the number of channels you offer.

A Practical Framework for Choosing the Right AI Support Channel

To apply all of this to your own business, evaluate each support workflow against the factors below rather than making one company-wide decision.

Score the Workflow Before Selecting the Technology

Rather than committing across the whole company, run a small pilot on a single workflow and test it against real numbers:

Resolution rate
Escalation rate
Incorrect tool calls
Average handling time
Customer satisfaction
Cost per resolved case
Failure recovery
Context preservation during handoff

Test the Channel With Real Customer Conversations

A polished demo is not evidence, because it is built to succeed. A meaningful pilot deliberately includes the messy reality your customers will bring:

Historical customer conversations
Misspellings and incomplete information
Accents and background noise for voice
Angry or confused customers
Unexpected requests
API failures
Authentication failures
Human escalation
Multiple turns and follow-up questions

For voice, test interruption handling, latency, pronunciation, silence, and transfer quality. For chat, test context retention, response usefulness, retrieval accuracy, and the ability to avoid repetitive loops.

The line worth remembering is this. A demo shows what the system does when the conversation goes as planned, while a pilot shows how it behaves when the customer does not.

Conclusion: Choose the Channel That Helps Customers Resolve Issues

Voice AI and chat AI are not competing technologies in every situation, and treating them as rivals leads to worse decisions than treating them as tools with different jobs.

Choose voice when real-time conversation, urgency, complexity, or emotion is central to the interaction. Choose chat when customers need speed, written information, asynchronous support, or digital self-service. Use both when customers naturally move between channels during a single support journey. The final decision should rest on workflow fit, integration depth, security, cost per resolution, and the quality of your human handoff.

So start with one high-volume support workflow, test both channels where it is practical to do so, and measure completed resolutions rather than chatbot deflection alone.

What It Costs to Build an AI Agent, From POC to Production

Dextra Labs — Fri, 18 Sep 2026 16:17:26 +0000

Ask three teams what it costs to build an AI agent and you will get three completely different numbers, often an order of magnitude apart. This is not because someone is lying to you, but because the phrase "AI agent" is hiding two very different things inside the same words.

A $15K proof of concept and a $150K production system might both be described as "an AI agent," yet they are not the same purchase at all. A POC typically proves that an agent can complete one workflow using sample data. Production, on the other hand, requires a great deal more:

Real integrations
Authentication
Evaluation
Guardrails
Monitoring
Failure handling
Security
Deployment
Ongoing maintenance

The current market spread reflects exactly this gap. Published 2026 estimates run from roughly $10K to $25K for focused POCs up to $50K to $150K and beyond for production agents, with enterprise systems extending well past that depending on complexity.

The thesis worth holding onto is simple. The expensive part of an AI agent is rarely making it work once, because the real cost lives in making it work reliably every single time.

How Much Does It Cost to Build an AI Agent in 2026?

Let us put the answer on the table before explaining it, because you came here for numbers rather than suspense. The figures below are planning ranges rather than universal market prices, since scope and the very definition of "production" vary enormously between teams.

Treat these as a map rather than a quote, because published 2026 estimates vary widely and any honest vendor will narrow the range only after understanding your scope.

The distinction that explains most of the price jump is the difference between two questions:

-POC asks: Can the agent do this?
-Production asks: Can it do this reliably, securely, repeatedly, at scale, with real users and real systems?

That shift from "can it" to "can it every time" is where the money goes, and it is the single most useful lens for reading any proposal you receive.

What Does an AI Agent POC Actually Cost?

A focused POC usually lands somewhere between $10K and $30K, but the number moves depending on what you pack into it. Understanding that scope is the difference between a POC that clarifies your decision and one that quietly turns into a half-built product.

A focused POC usually includes:

One defined workflow
One primary model
Limited data
One or two integrations
A basic interface
Initial evaluation
Basic logging
Human review

It usually does not include:

Full production security
Complex multi-system integrations
Extensive monitoring
High availability
Large-scale load testing
Full compliance architecture

The difference in ambition becomes obvious with an example. A ticket-triage agent that reads support tickets, classifies them, retrieves relevant knowledge, and drafts a response is a fundamentally simpler thing than an agent that can resolve the ticket outright, update the CRM, issue a refund, and trigger downstream workflows. The first proves feasibility, while the second is a production system wearing a POC's clothing.

The principle to keep in mind is that a good POC should reduce uncertainty rather than pretend you have already built the final product. Current 2026 guidance increasingly treats the POC as a feasibility and cost-validation exercise, not a miniature production deployment, and that framing will save you a great deal of money.

Why the Jump From POC to Production Costs So Much More

This is the heart of the whole question, because the leap from a working demo to a trustworthy system is where most of the engineering budget actually goes. It concentrates in four places.

1. Integrations Become Real

POC: a mock API or a single limited connector that behaves nicely.
Production: CRM, ERP, ticketing, internal APIs, identity, and databases, all at once.

Each of those connections adds engineering, authentication, permissions, error handling, testing, and ongoing maintenance, which is why current industry estimates consistently name integrations as one of the largest cost drivers of the entire project.

2. Evaluation Becomes Continuous

POC: "it worked in the demo."
Production: "it passed 1,000+ evaluation cases and continues to pass them after every change."

That shift brings golden datasets, regression tests, edge cases, hallucination testing, tool-use evaluation, and model comparison, all maintained over time rather than run once and forgotten.

3. Guardrails Become Engineering

In a prototype, safety is mostly a matter of watching the agent closely. In production, safety becomes real engineering work:

Permission boundaries
Validation
Human approval
Fallbacks
Retry limits
Audit logs

4. Reliability Becomes a Requirement
Production means the system has to stay up and behave predictably, which brings its own layer of work:

Monitoring
Alerts
Error handling
Observability
Uptime
Incident response

The blunt way to summarize this whole section is that production cost is largely the price of everything that happens when the happy path stops working.

The 7 Biggest Factors That Drive AI Agent Development Cost

If you want to understand your own likely budget, these are the seven levers that move it the most. This section is also where learning how to build AI agents economically really comes down to knowing which of these you can simplify.

1. Workflow Complexity

One simple workflow costs less than an agent coordinating fifteen steps across multiple systems, because every additional step is another place to reason, fail, and test.

2. Number of Integrations

More tools mean more of everything that costs money:

Connectors
Permissions
Failure points
Testing

CRM, ERP, email, payment, ticketing, databases, and internal APIs each add their own version of this list.

3. Data Complexity

Clean, structured data is cheap to work with. Cost rises sharply with:

PDFs
Emails
Unstructured documents
Conflicting knowledge
Legacy databases

4. Agent Architecture

Single-agent workflows are generally simpler than the alternatives, each of which multiplies both engineering and evaluation effort:

Multi-agent systems
Planner/executor architectures
Long-running agents
Agent-to-agent coordination

5. Model Choice

Different tasks may require different models, and production architecture does not mean using the most expensive model everywhere. A routing strategy can use:

A smaller model for classification
A stronger model for reasoning
A specialized model for extraction

6. Security and Compliance

Costs climb when you need PII handling, encryption, audit trails, role-based access, HIPAA/PCI/SOC 2 controls, and data residency. Some 2026 estimates put compliance-heavy projects 15 to 25% or more above a comparable base build, though the real figure depends heavily on your scope.

7. Expected Usage

A low-volume internal agent and a customer-facing agent handling a million interactions a month have completely different operating economics, and that expected volume shapes both the architecture and the running bill.

The Hidden Cost: Running the AI Agent After Launch

Here is the part that catches teams off guard. Your build quote is only the opening line of the bill, because an agent in production keeps spending money every day it runs.

The monthly costs stack up across several categories at once:

- Model/API usage: input tokens, output tokens, tool calls, reasoning loops
- Infrastructure: compute, databases, vector storage, queues, hosting
- Observability: logs, traces, evaluation, monitoring
- Maintenance: prompt updates, knowledge updates, integration changes, model changes, regression testing
- Human oversight: review, exception handling, operations

Recent industry coverage makes exactly this point, noting that total cost of ownership extends well beyond the initial build into model usage, maintenance, monitoring, and organizational costs. The market data backs it up, with maintenance now commonly running 15 to 25% of the build cost each year and three-year TCO frequently landing at 1.5 to 2 times the original build.

A useful way to hold all of this in your head is a single formula:

3-Year AI Agent TCO = Build + Infrastructure + Model/API Usage + Monitoring + Maintenance + Human Operations

Skip any of those terms and your budget is fiction.

How Much Does It Cost to Run an AI Agent Each Month?

This deserves its own answer because operating cost is a genuinely separate question from build cost. The ranges below are planning figures rather than fixed market rates, since your actual bill depends heavily on how the agent is used.

Simple internal agent: $300–$1,500/month
Production workflow agent: $1,500–$5,000+/month
High-volume or multi-agent system: $5,000–$15,000+/month

The major variables are interaction volume, token consumption, model choice, the number of tool calls, context length, infrastructure, and monitoring requirements.

The key insight from current 2026 discussions is that development complexity and operating cost are separate variables. A technically complex agent with low usage can easily cost less to run than a simple customer-facing agent handling enormous volume, which is why you have to model both independently.

Where AI Agent Projects Usually Go Over Budget

Budget overruns tend to follow a predictable script, and recognizing the plot early is how you avoid it. Here are the five places projects most reliably slip.

1. The scope starts too broad: "Build us an AI agent for sales" is a wish, not a specification, and a vague brief invites an expensive, unfocused build.

2. Integrations are underestimated: The model is ready in a week. The ERP integration is not, and that gap is where timelines quietly double.

3. Evaluation is added too late: Testing becomes far more expensive when the entire system is already built and you are retrofitting checks onto finished code.

4. Production requirements appear after the POC: Security, SSO, logging, auditability, and uptime often surface only once everyone assumes the hard part was done.

5. The team optimizes the model instead of the workflow: The cheapest model is not useful if the architecture requires ten unnecessary calls.

The honest takeaway is that most overruns do not come from the model suddenly becoming expensive. They come from discovering too late what "production-ready" actually requires.

How to Reduce AI Agent Development Costs Without Building a Toy

Cutting cost does not have to mean cutting corners, as long as you are disciplined about where you economize. These seven habits keep a build lean without leaving you with a prototype that cannot grow up.

1. Start with one workflow. Do not build a platform before proving a single use case.

2. Use existing foundation models first. Do not fine-tune unless there is a demonstrated reason.

3. Limit integrations in the POC. Prove the core workflow before connecting everything.

4. Build evaluation early. Catch bad architecture before production engineering begins.

5. Use model routing. Do not send every task to your most expensive model.

6. Separate POC from production architecture. The POC should answer feasibility questions, while production solves reliability and scale.

7. Put a budget cap on inference. An agent stuck in a loop should never be able to generate an unlimited bill.

Build vs Buy: Is Building an AI Agent Even Worth the Cost?

Before you commit a budget, it is worth asking whether you should build at all, and the honest answer is that it depends on your workflow. This is the real substance of the build vs buy AI agents decision, and treating it seriously earns you credibility rather than costing it.

Build when:

The workflow is highly proprietary
Deep system integration is required
You need control over architecture and data
Existing products cannot handle the workflow

Buy when:

The use case is standardized
A mature product already exists
Customization requirements are limited

Partner when:

You need custom development
Internal engineering capacity is limited
Multiple enterprise systems must be integrated
You need help moving from POC to production

The point that ties it together is one many vendors will not tell you. The cheapest way to build an AI agent is sometimes not to build one at all.

A Practical AI Agent Budgeting Framework

Before you request a single vendor quote, walk through these six steps so you arrive at the conversation with a real budget rather than a hopeful guess. Each step sharpens the number and exposes the assumptions hiding inside it.

1. Define the workflow. What exactly will the agent do?
2. Count the systems. How many APIs and tools does it need?
3. Estimate volume. How many tasks or interactions per day?
4. Define autonomy. What can it read, recommend, execute, and escalate?
5. Define production requirements. Security, monitoring, compliance, uptime.
6. Estimate TCO. Work through POC → Production → Monthly Operations → Year 1 → 3-Year TCO.

Here is the test that makes this framework worth using. If a vendor gives you a single cost to build an AI agent without asking these questions first, the number is not a budget yet. It is a guess dressed up as a quote.

The Cost of an AI Agent Is the Cost of Making It Reliable

A POC proves possibility, and production proves reliability, and the gap between those two words is where most of the engineering cost quietly lives. Once you see the problem that way, the strange spread in vendor quotes stops being mysterious and starts being informative.

So do not budget only for the model or the first working demo. Budget for the integrations, the evaluation, the security, the monitoring, the inference, the maintenance, and the people responsible for keeping the whole thing reliable over time.

The right question was never "how much does it cost to build an AI agent?" The better question, the one that actually protects your budget, is "how much will it cost to make this agent reliable enough to trust with real work?"

Custom or Off-the-Shelf AI Customer Service Agents: Which Approach Fits Your Business?

Dextra Labs — Thu, 17 Sep 2026 07:36:40 +0000

You can get an AI customer service agent running surprisingly quickly in 2026. The harder question is whether the agent you can deploy in a few days is actually capable of handling the workflows your business cares about.

An off-the-shelf agent might comfortably handle:

FAQs
Basic ticket triage
Knowledge-base questions
Simple customer requests

Things change, though, the moment the agent needs to do real work:

Access proprietary data
Update your CRM
Process refunds
Follow complex business rules
Coordinate multiple systems
Operate inside regulated environments

So the right question is not "can we build this?" or "is there a tool for this?" The question that actually matters is how much of your customer-support workflow an existing product can handle without forcing you to redesign the workflow around the product. The workflow should come before the build-versus-buy decision, not after it.

Custom vs. Off-the-Shelf AI Customer Service Agents

Before comparing the two approaches, it helps to define them clearly, because the words get used loosely and the difference is not always obvious from a vendor's marketing.

What Is an Off-the-Shelf AI Customer Service Agent?

An off-the-shelf agent is a prebuilt product you configure rather than construct. It typically provides:

Prebuilt customer-service workflows
Knowledge-base integration
Standard CRM and help-desk connectors
Conversation management
Analytics
Human handoff
Vendor-managed infrastructure

Its main advantage is speed, since most of the engineering has already been done for you.

What Is a Custom AI Customer Service Agent?

A custom agent is built around your business rather than the other way around. It is shaped by your:

Customer journey
Business rules
Data
APIs
Internal systems
Permissions
Escalation logic

Its main advantage is control and workflow fit.

The distinction worth holding onto is that custom is not automatically better. Off-the-shelf gives you a working system faster, while custom gives you more control over how the system actually works, and which of those matters more depends entirely on your situation.

Start With the Workflow, Not the Technology

The most common mistake is evaluating products before mapping the workflow they are meant to serve. Map the actual support process first, because that map tells you more than any demo will.

Consider a customer who says, "my order hasn't arrived, can you fix it?" The same sentence pulls two very different responses depending on the agent behind it.

An off-the-shelf agent might:

Identify the intent
Search the knowledge base
Provide shipping information

A custom agent might:

Authenticate the customer
Query the order system
Check logistics data
Determine whether the shipment qualifies for intervention
Create a replacement
Update the CRM
Notify the customer
Escalate exceptions

The difference here is not "better AI." The difference is workflow access and control, which is a matter of what the agent is allowed and able to reach rather than how clever its language model is.

To size that gap for your own case, ask a few diagnostic questions before you look at a single product:

How many systems does the workflow touch?
How many decisions does the agent make?
How many actions can it execute?
How proprietary are the business rules?
What happens when the normal workflow fails?

The answers will tell you more than a vendor demo ever could, because they describe your reality instead of the product's best-case scenario.

When an Off-the-Shelf AI Customer Service Agent Makes More Sense

Buying is often the smart engineering decision, and it deserves an honest case rather than a straw man. Off-the-shelf tends to win in four situations.

- Your use case is standard: If the work is mostly FAQs, order tracking, ticket classification, knowledge retrieval, and basic troubleshooting, a mature product already does this well, and this is exactly where AI agents for customer service deliver value fastest.

- You need to launch quickly: If the business needs something operational in weeks rather than months, a prebuilt product eliminates a significant amount of engineering work that would otherwise sit between you and production.

- Your existing stack is already supported: If the product has reliable integrations with your CRM, help desk, knowledge base, and communication channels, there may be very little reason to rebuild connectors that already exist and are maintained for you.

- You don't want to own the infrastructure: With a vendor product, someone else handles model changes, scaling, monitoring, infrastructure, and product maintenance, which is real ongoing work you get to skip.

The takeaway is straightforward. If the workflow is common and the product already handles most of it well, building your own agent may just mean rebuilding infrastructure someone else has already solved.

When a Custom AI Customer Service Agent Makes More Sense

Now flip the argument, because the same logic that favors buying for standard work favors building when the work is anything but standard. Custom development becomes compelling in five situations.

- You have proprietary workflows: Your support process is not simply "answer a question," but a sequence of unique business rules and multi-step decisions that no generic product was designed around.

- Deep integrations are required: The agent needs to operate across your CRM, ERP, billing, order management, internal APIs, and proprietary databases, and it needs to act in them rather than just read from them.

- The customer experience itself is differentiated: If support is part of your competitive advantage, a generic interface and a generic flow may not be enough to protect what makes you distinct.

- You need granular control: Custom permissions, data residency, auditability, internal security requirements, and custom escalation logic are all far easier to guarantee when you own the architecture.

- Existing products hit a ceiling: The strongest signal is not that a product lacks a single feature. It is that you find yourself repeatedly building workarounds to make the product behave the way your business already works.

The line to remember is this. Build when the workflow is the differentiator, not simply because building feels more flexible.

The Hidden Cost of "Just Buying a Platform"

Buying is not automatically the cheap option, and the sticker price rarely tells the whole story once customization begins. The costs tend to accumulate quietly:

Subscription
Implementation fees
Custom connectors
Professional services
Usage-based pricing
Premium integrations
Additional seats
Data storage
Higher enterprise tiers

Beyond the line items, you also inherit a set of constraints that shape what you can do:

The vendor's data model
The vendor's workflow assumptions
The vendor's model choices
The vendor's release schedule
The vendor's API limitations
The vendor's pricing changes

The insight here is that a platform can stay inexpensive right up until you start paying to make it behave like the custom system you chose not to build.

That said, custom carries its own hidden costs, and honesty cuts both ways. Building means owning engineering, monitoring, security, model upgrades, maintenance, infrastructure, and on-call responsibility. The right comparison is therefore total cost of ownership, not a subscription price set against a one-time development quote.

Custom Doesn't Mean Building Everything From Scratch

There is a persistent misconception, especially among developers, that "custom" means training your own language model. It almost never does, and clearing that up changes the economics of the decision.

A custom agent can lean on infrastructure that already exists:

OpenAI, Anthropic, or Google models
Open-source models
Agent frameworks
Vector databases
Existing observability tools
Managed infrastructure

The custom part is not the model at all. It is usually the layer that makes the agent yours:

Workflow orchestration
Tool integration
Business logic
Context engineering
Permissions
Evaluation
Guardrails
User experience

The takeaway is freeing once it lands. You do not need to build the model to build the agent, which is exactly why modern AI agent development services focus on orchestration and integration rather than on training foundation models from zero.

Build vs. Buy: Compare These 7 Things Before Deciding

When you are ready to weigh the two approaches directly, this is the comparison framework to use. Start with the summary table, then work through the seven questions beneath it.

1. Time to value. How quickly do you genuinely need to be in production?

2. Workflow complexity. How many steps and systems does the process actually involve?

3. Integration depth. Can the product execute the actions you need, or only retrieve information?

4. Data and security. Can you meet your requirements without constantly fighting the platform?

5. Total cost of ownership. Compare two to three years, not just month one.

6. Engineering ownership. Who handles the failure at 2 AM when something breaks?

7. Vendor lock-in. Can you export your data, conversation history, workflows, knowledge, and configuration if you leave?

Answering these seven honestly usually settles the build vs buy AI customer service agent decision more effectively than any feature comparison, because they force you to weigh the whole engagement rather than the first month of it.

The Hybrid Approach: Buy the Commodity, Build the Differentiator

The choice does not have to be binary, and for many teams the best answer sits in the middle. A hybrid architecture buys the parts that are already solved and builds the parts that make you distinct.
A sensible split often looks like this.

Off-the-shelf handles the commodity layer:

Basic FAQ handling
Knowledge retrieval
Conversation management

Custom handles the differentiating layer:

Proprietary workflows
Internal APIs
Complex business logic
High-risk actions
Specialized escalation

This lets you avoid rebuilding commodity infrastructure while keeping real control over the workflows that matter to your business. The takeaway is that the smartest architecture may be neither fully custom nor fully off-the-shelf, but custom where your business is unique and standard where the problem is already solved.

A Practical Decision Framework for Your AI Customer Service Agent

If you want a quick way to point yourself in the right direction, run through these two checklists honestly before committing to either path.

Lean toward off-the-shelf if most of these are "yes":

Is the workflow relatively standard?
Does the platform already integrate with our systems?
Can it handle at least 80% of the required workflow?
Can we meet our security requirements?
Can we launch within our required timeline?
Is the customization we need limited?

Consider custom if several of these are "yes":

Does the agent need proprietary workflows?
Does it need deep system access?
Are there complex business rules?
Do we need custom permissions?
Is customer experience a competitive differentiator?
Are platform limitations already creating workarounds?
Do we need more control over data and architecture?

Then ask one final question that cuts through the rest. If the off-the-shelf product disappeared tomorrow, how much of your customer-support process would have to be redesigned? If the answer is "almost everything," you may have quietly built your workflow around the vendor rather than around your business.

Test Before You Commit: Run a Real Customer-Service Pilot

Whichever way you are leaning, do not make the final call from a polished demo, because a demo is designed to show you the happy path. Run a real pilot against your own conditions instead.

Test the agent with:

Real historical conversations
Messy customer inputs
Edge cases
Real knowledge
Actual integrations
Human escalation

Then measure what actually matters:

Resolution rate
Escalation rate
Incorrect actions
Tool failures
Response time
Cost per resolution
CSAT

The point is simple but easy to skip under time pressure. A 30-minute demo tells you what the agent can do when everything goes right, while a real pilot tells you what happens when it doesn't, and for a technical buyer that second answer is worth far more than any feature checklist.

Conclusion: Choose the Architecture That Fits the Workflow

Custom is not automatically better, and off-the-shelf is not automatically cheaper. The right decision depends on your workflow complexity, integration depth, required control, time to production, total cost, and how strategically important customer service is to your business.

If your workflow is standard and an existing product handles it reliably, buying may be the most practical engineering decision you can make. If your workflow is deeply integrated, proprietary, or central to the customer experience, custom development may well justify the additional investment.

And if you land somewhere in between, do not force a binary choice. Buy the infrastructure you do not need to reinvent, and build the workflows that actually differentiate your business.

How Finance Teams Should Evaluate AI Agents Before Choosing One

Dextra Labs — Sat, 12 Sep 2026 20:17:55 +0000

The finance leader's inbox in 2026 looks different than it did two years ago. Where vendor pitches once focused on dashboards, analytics platforms, and workflow automation tools, the current wave is AI agents, autonomous systems that promise to handle everything from invoice processing to fraud detection to regulatory compliance without human intervention.

The promises are impressive. The evaluation criteria most finance teams are using to assess them are not.

We've watched finance teams evaluate AI agents the same way they evaluate traditional software: feature checklists, vendor demos on curated data, and reference calls with handpicked customers. This approach worked when you were buying a tool that did what you configured it to do. It fails when you're buying a system that makes decisions autonomously, because the questions that determine whether an autonomous system works in your environment are fundamentally different from the questions that determine whether a configured tool works.

The AI agents in finance market have matured enough that there are genuine, production-tested options across accounts payable, lending, fraud detection, compliance monitoring, and customer operations. The challenge isn't finding options. It's evaluating them against the criteria that actually predict whether the agent will deliver value in your specific environment, not just in a vendor's demo.

This is the evaluation framework we've developed from working with finance teams deploying agents across these domains. It covers the seven areas that most reliably predict deployment success, and for each one, the specific questions that separate agents ready for production from agents ready for demos.

Evaluation area one: accuracy on your data, not their data

Every vendor will show you accuracy numbers. The numbers will be impressive. They will also be measured on data that the vendor selected, cleaned, and optimised for.

The evaluation that matters: run the agent on your actual data. Your invoices, with your vendors' formatting quirks. Your loan applications, with the document quality your borrowers actually submit. Your transaction data, with the patterns your customers actually produce.

The accuracy gap between vendor demo data and your production data is typically 8 to 15 percentage points. An agent that extracts invoice data at 97% accuracy on clean PDFs from the vendor's test set may extract at 84% accuracy on the scanned documents and phone photographs your vendors actually send. An intent classification model that routes support queries at 92% accuracy on the vendor's curated test set may route at 78% accuracy on the code-mixed Hinglish your Indian customer base actually writes.

The specific questions to ask: can we run a pilot on our own data before committing? What's the accuracy on document formats that aren't clean digital PDFs? What's the performance when the input language is informal, multilingual, or domain-specific?

If the vendor resists a pilot on your data, that resistance is itself an evaluation finding.

Evaluation area two: exception handling architecture

This is the area that separates production-ready agents from impressive demos, and it's the area that most finance teams skip during evaluation because it's less exciting than the happy-path demonstration.

An AI agent in a finance environment will encounter exceptions on 20 to 40 percent of transactions. Invoices that don't match a purchase order. Loan applications with unusual structures. Transactions that fall into ambiguous regulatory categories. The agent's value isn't determined by how it handles the 60 to 80 percent that's straightforward. It's determined by how it handles the 20 to 40 percent that isn't.

There are three architecturally different approaches to exception handling, and the approach determines the agent's operational character.
Agents that stop on exceptions route every non-standard case to a human without classification or context. The human receives an alert that says, in effect, "something didn't match" and has to investigate from scratch. This is the simplest architecture. It's also the least valuable because the investigation burden on the human team remains high.

Agents that classify and route exceptions identify the type of discrepancy, assemble the relevant context, and route to the appropriate human with the specific issue pre-identified. The human starts with understanding rather than investigation. This architecture reduces resolution time per exception by 40 to 60 percent because the discovery work is already done.

Agents that resolve within tolerance handle a subset of exceptions autonomously, quantity variances within defined tolerance bands, known vendor format variations, predictable discrepancy patterns and route only the genuinely ambiguous cases to humans. This architecture delivers the highest automation rate but requires more sophisticated design and careful calibration of the autonomy boundaries.

The specific questions to ask: show me what happens when the agent encounters an exception. What information does the human reviewer receive? Can the agent resolve any exception types autonomously, and if so, what governs the tolerance thresholds? What's the exception rate on real-world data versus demo data?

Evaluation area three: integration depth with your existing systems

The agent's intelligence is only as useful as its ability to connect with the systems where your finance data actually lives. An agent that processes invoices brilliantly but can't connect to your ERP to verify purchase orders is an agent that creates manual work rather than eliminating it.

Integration depth has three levels, and the level determines the agent's operational value.

Read-only integration means the agent can pull data from your systems but can't write back. It can check an invoice against a purchase order but can't update the invoice status or initiate the payment. The human team handles every downstream action. This is the minimum viable integration level and it's where most vendor pilots operate.

Read-write integration means the agent can both pull data and update records. It can match the invoice, approve it within policy, update the status in the ERP, and route for payment. This is the level required for genuine end-to-end automation.

Bidirectional event-driven integration means the agent responds to events from your systems in real time, a new invoice arrives, a transaction is processed, a regulatory update is published, rather than polling on a schedule. This is the level required for real-time monitoring use cases like compliance and fraud detection.

The specific questions to ask: which ERP systems do you have production integrations with? Is the integration read-only or read-write? Does the agent poll for data or respond to events? What happens to the agent's operation if the ERP is temporarily unavailable?

The integration question matters more than the AI question for most finance deployments because the integration work typically takes longer and costs more than the AI development itself.

Evaluation area four: compliance and audit trail architecture

Finance operates in a regulated environment. Every autonomous decision the agent makes needs to be documented, traceable, and explainable, not just for internal audit but for regulatory examination.

The audit trail requirements for an AI agent are more demanding than for traditional automation because the agent makes judgment calls, not just rule-based determinations. When a rules engine approves a transaction, the audit trail shows which rule matched. When an AI agent approves a transaction, the audit trail needs to show the reasoning, what data the agent considered, what assessment it made, and why it reached the conclusion it did.

The best AI agents for finance industry deployments produce audit trails that include three components for every decision. The input, exactly what data the agent received and from which systems. The reasoning, the factors the agent weighed, the confidence level of its assessment, and the specific rule or policy the decision maps to. The output, what action the agent took or what recommendation it made, timestamped and linked to the input and reasoning.

The specific questions to ask: show me the audit trail for a single processed transaction. Can a compliance officer reconstruct the agent's reasoning for any decision? Does the audit trail capture the data state at the time of decision, or does it reference data that may have changed? How are audit records stored and for how long?

If the vendor can't show you a complete audit trail for a decision the agent made, the agent isn't ready for a regulated finance environment.

Evaluation area five: the human-in-the-loop design

The boundary between what the agent handles autonomously and what requires human review is the most consequential design decision in any finance AI deployment. It determines the automation rate, the error rate, the compliance posture, and the team's trust in the system.

The evaluation should examine three aspects of this boundary.

Where is the boundary? Which transaction types, amounts, risk levels, and complexity categories does the agent process autonomously versus escalate? Are these boundaries configurable by your team, or are they fixed by the vendor? Can they be adjusted as confidence in the system grows?

How does escalation work? When the agent escalates to a human, what context does the human receive? Can the human override the agent's recommendation easily, or does overriding require navigating a cumbersome process? Is the override captured in the audit trail?

Is the boundary calibrated or arbitrary? Was the autonomy boundary set through parallel testing, running the agent alongside human processes and measuring agreement rates, or was it set based on the vendor's general recommendations? The former produces boundaries tuned to your specific risk profile. The latter produces boundaries tuned to someone else's.

The specific questions to ask: what's the auto-processing rate on real-world data? What's the false positive rate on escalated items, how often does the agent escalate something that turns out to be routine? Can we adjust the autonomy thresholds ourselves, or do we need the vendor to reconfigure?

Evaluation area six: total cost of ownership, not just license fees

The pricing conversation for AI agents is more complex than traditional software licensing because the cost structure has components that don't exist in conventional tools.

License or subscription fees are the visible cost. API or inference costs are the variable cost that scales with transaction volume and can surprise teams that didn't model usage accurately. Integration development costs are often larger than expected, especially in environments with legacy ERPs or multiple source systems. Ongoing maintenance costs include model updates, threshold recalibration, and the monitoring that ensures the agent's performance doesn't degrade over time.

The specific questions to ask: what's the total monthly cost at our transaction volume, including inference costs? How does cost scale if our volume doubles? What's included in the subscription versus what's billed separately? What does ongoing maintenance and support cost after the initial deployment?

Model the three-year total cost of ownership, not the annual license fee. The three-year view captures the integration investment, the ongoing operating costs, and the scaling economics that determine whether the agent becomes more or less cost-effective as your volume grows.

Evaluation area seven: vendor stability and deployment maturity

The AI agent market is young enough that vendor stability is a legitimate evaluation criterion. Startups pivot. Products get acquired. Pricing models change. A system your team builds workflows around needs to be operated by a company that will be supporting it in three years.

The maturity indicators that matter: how many production deployments does the vendor have in finance specifically? How long has the longest-running deployment been operating? What's the customer retention rate? Is the product revenue-funded or dependent on the next funding round?

The specific questions to ask: can we speak with a customer who's been running your agent in production for more than twelve months? What happens to our deployment if your company is acquired? What's your product roadmap for the next eighteen months?

These aren't comfortable questions to ask. They're essential questions to ask before committing your finance operations to a vendor's continued existence and support.

The evaluation process that works

The framework above has seven areas. The evaluation process that works doesn't try to assess all seven simultaneously.

Start with a data pilot. Before evaluating anything else, run the agent on your data and measure accuracy. If the accuracy of your data doesn't meet your threshold, nothing else matters. This step takes two to four weeks and filters out agents that demo well but don't perform on real-world inputs.

Evaluate the exception architecture second. Once accuracy on clean cases is validated, the exception handling determines the operational value. Observe how the agent handles the 20 to 40 percent of transactions that aren't straightforward. This is where the difference between a demo-ready agent and a production-ready agent becomes visible.

Assess integration depth and compliance architecture third. These are the requirements that determine whether the agent can actually operate in your environment or whether it creates additional manual work despite its AI capability.

Evaluate cost and vendor stability last. These are important but they're the wrong starting point because they distract from the operational questions that determine whether the agent works. A cheap agent that doesn't handle your exceptions well costs more than an expensive agent that does.

For finance teams that have completed the evaluation and are ready to build or deploy, the custom AI agent development company practice at Dextra Labs works with finance operations teams across the full deployment lifecycle, from the initial data pilot and workflow assessment through agent architecture, system integration, compliance engineering, and the ongoing optimisation that keeps the agent performing as your operations evolve.

The AI agent market for finance is mature enough that real options exist. The evaluation framework determines whether the option you choose delivers real value or becomes an expensive experiment. The seven areas above are the questions that predict which outcome you'll get.

We Tested 10 AI Agent Builders for Customer Service on the Same Use Case, Here's the Integration Reality

Dextra Labs — Sun, 30 Aug 2026 14:48:01 +0000

We kept running into the same thing on client calls. A team picks an AI agent builder based on a comparison table, signs the contract, and then spends three months discovering that "integrates with your CRM" meant reads from your CRM, not writes back to it with the custom validation rules your ops team spent four years building.

So we stopped trusting feature matrices and ran an actual test. Ten builders, one use case, same backend. Here's what broke, what held, and what quietly locked us in.

The Test

We built one realistic customer service flow and forced every platform through the exact same thing:

1. Order status lookup pull a live order from a mock e-commerce backend (Postgres + a REST API with auth, not a CSV upload).
2. Refund processing actually write a refund back through an approval workflow, not just draft a reply saying a refund is "on its way."
3. Escalation to a human hand off with full context (order ID, customer sentiment, what the agent already tried) into a ticketing queue.

That third step matters more than people expect. Anyone can deflect. The question is whether the handoff carries state or dumps the customer back to square one.

We wired each builder to the same endpoints. No special-casing. If a platform needed a middleware shim to talk to our API, that shim counted against it, because in production, that shim is your problem to maintain.

A note on honesty: we build custom AI agents for a living, so we have a horse in this race. We tried to counter that by scoring on observable behavior, not vibes. Where a platform beat our expectations, we said so. Two of them genuinely surprised us.

What "Integration Depth" Actually Means

Before the results, let's define the thing everyone measures wrong.

Most comparison posts count number of integrations. That number is close to meaningless. What you actually care about is:

Read vs. write Reading a customer record is table stakes. Executing a state-changing action (refund, cancel, upgrade) through your business logic is the hard part. Plenty of builders quietly stop at read.
Auth reality OAuth2 with token refresh against a real API, or does it assume a static key you'd never ship to prod?
Custom endpoints Can it call your API with your schema, or only the 40 SaaS logos on its integrations page?
Failure handling When your backend returns a 500, does the agent retry, escalate, or confidently tell the customer their refund succeeded?
State on handoff Does escalation carry context, or reset it?

That's the rubric. Now the matrix.

The Integration Matrix

Scored 1–5 on how each builder handled our specific test. This is not a general product review, it's how they behaved on order-status + refund + escalation against a real backend.

(Scores reflect our single use case and our backend. Your mileage will differ with different systems, that's exactly the point.)

What Actually Happened (The Parts You Can't Put in a Table)

The refund step separated the field instantly. Roughly half the builders handled "look up the order" beautifully and then got shy about the write. A few would draft the refund and wait for a human to click the button, which is fine, but it's not autonomous resolution, it's a fancier ticket. If a vendor's demo only ever reads, ask them to process a refund live. Watch the energy in the room change.

Auth is where the marketing dies. Read-only connectors against a well-known SaaS API? Everyone's great. Point them at a custom endpoint with OAuth2 and token refresh, and the low-code platforms started needing "a quick middleware layer." That layer is a service you now own, monitor, and get paged for at 2am. Count it as part of the platform's real cost.

Rasa and the custom build behaved the way engineers wish everything did because both give you the actual execution layer. Rasa's approach of pairing LLM reasoning with deterministic business logic meant the refund path did what we told it to, every time, instead of what the model felt like doing. The tradeoff is real: you need people who can build and maintain it. There's no free lunch, just a lunch you cook yourself.

Salesforce Agentforce was the strongest inside its own gravity well. If your world already runs on Service Cloud, the native access to records and cases is genuinely hard to beat. Step one inch outside the ecosystem and the same tight coupling becomes the thing holding you in.

Failure handling is the silent killer. We deliberately made our backend return errors mid-conversation. The builders that scored lowest didn't crash, they did something worse: they answered confidently and wrongly. An agent that tells a customer "your refund is processed" when the API 500'd is a support ticket and a trust problem. The ones that scored well treated an unknown backend state as an escalation trigger, not a guess.

The Decision Framework (Skip the 40-Row Spreadsheet)

After running this, the choice collapses to four questions:

1. Does the agent need to do things, or just answer? If it only answers from a knowledge base, most builders are fine and you're overthinking it. The moment it takes state-changing actions, integration depth becomes the whole ballgame.

2. How weird is your backend? Standard Salesforce/Zendesk stack → most platforms integrate cleanly. Proprietary CRM, legacy middleware, custom approval chains → you need real extensibility, and off-the-shelf starts fighting you.

3. What happens at scale? Per-resolution pricing is great at 10k conversations and a budget meeting at 500k. Model the three-year cost, not the pilot.

4. Who owns it after launch? If the answer is "engineering," self-hosted or custom pays off. If it's "the support team, alone," lean low-code and accept the ceiling.

There's no universal winner here. There's a winner for your backend, your volume, and your team, which is a much more useful thing to know.

Where This Leaves You

The uncomfortable takeaway: the builder that demos best is rarely the one that ships cleanest. Demos run on happy paths and standard connectors. Production runs on your weird auth, your legacy system, and the Tuesday your backend throws a 500 in the middle of a refund.

If your stack is standard and your agent mostly answers questions, buy off-the-shelf and move on. If your agent has to act across proprietary systems under real compliance, that's where we live, we build custom AI agents around the backend you already have instead of asking you to bend your operations around a platform.

Feature lists lie. Integration depth is what determines whether an agent ships. We ranked 10 builders on what actually matters, the full breakdown and the buyer's guide is here: best AI agent builder for customer service.

Have you run a builder against a genuinely non-standard backend? I'm curious which ones held up for you, the failure-handling behavior especially.

15 NLP Techniques Every Backend Developer Should Know in 2026 (With Code Examples)

Dextra Labs — Thu, 27 Aug 2026 06:50:04 +0000

NLP stopped being a data science specialty about two years ago. It's backend infrastructure now.

If you're building APIs that process user input, handle search, manage support tickets, parse documents, or power any feature where humans communicate with your system in natural language, you're doing NLP whether you call it that or not.

The difference between a backend developer who understands NLP techniques and one who doesn't is the difference between building a search endpoint that actually finds what users want and building one that matches keywords and returns garbage for anything slightly ambiguous.

This is the reference guide we wish we'd had when we started integrating NLP into production backend services. Fifteen techniques, each with a runnable code snippet, ordered from the most immediately useful to the most architecturally advanced.

Every example runs in Python. Install the dependencies as needed, we'll note them for each technique.

1. Text tokenization

The atomic operation. Everything else depends on splitting text into meaningful units.

import spacy
nlp = spacy.load("en_core_web_sm")

text = "Dr. Smith's appointment at 3:30pm was rescheduled."
doc = nlp(text)
tokens = [token.text for token in doc]
# ['Dr.', 'Smith', "'s", 'appointment', 'at', '3:30pm', 'was', 'rescheduled', '.']

SpaCy handles the edge cases that naive split-on-whitespace misses, abbreviations, contractions, timestamps. If your backend processes any user-generated text, tokenization is step zero.

2. Named entity recognition (NER)

Extracting structured data from unstructured text. Names, dates, amounts, locations, the things your database actually needs.

doc = nlp("Send $5,000 to Acme Corp in Singapore by March 15th")
for ent in doc.ents:
    print(f"{ent.text:20} {ent.label_}")
# $5,000               MONEY
# Acme Corp             ORG
# Singapore             GPE
# March 15th            DATE

We use NER on every inbound support ticket to auto-tag customer, product, and amount entities before the ticket enters the routing queue. Takes three lines to add and saves the support team from manually tagging 200 tickets a day.

3. Sentiment analysis

Classifying text as positive, negative, or neutral. Useful for prioritising support queues, monitoring reviews, and flagging escalation risks.

from transformers import pipeline

classifier = pipeline("sentiment-analysis", 
                      model="distilbert-base-uncased-finetuned-sst-2-english")
result = classifier("The delivery was late and the product was damaged")
# [{'label': 'NEGATIVE', 'score': 0.9997}]

The production pattern: run sentiment on every incoming customer message. Route negative-sentiment messages with high confidence scores to the priority queue. The model catches the tone that keyword filters miss, "I guess it's fine" reads as negative even though it contains no negative keywords.

4. Intent classification

Determining what the user wants to do, not just what they said. The backbone of any automated routing system.

from transformers import pipeline

classifier = pipeline("zero-shot-classification",
                      model="facebook/bart-large-mnli")
text = "I need to change my shipping address before the order ships"
labels = ["order_modification", "refund_request", "tracking", "account_update"]
result = classifier(text, labels)
# label: 'order_modification', score: 0.82

Zero-shot classification is the technique that changed our approach to ticket routing. You define the intent categories. The model classifies without training data for each category. When your product team adds a new feature category, you add a string to the labels array, no retraining required.

5. Text embedding generation

Converting text into dense vector representations that capture semantic meaning. The foundation for search, similarity, and RAG systems.

from sentence_transformers import SentenceTransformer

model = SentenceTransformer("all-MiniLM-L6-v2")
texts = [
    "How do I reset my password?",
    "I forgot my login credentials",
    "What are your shipping rates?"
]
embeddings = model.encode(texts)
# embeddings.shape: (3, 384)
# Cosine similarity between [0] and [1]: 0.82 (semantically similar)
# Cosine similarity between [0] and [2]: 0.13 (semantically different)

Embeddings are how your backend understands that "reset my password" and "forgot my login credentials" are the same request even though they share zero keywords. Store these in a vector database and you've got semantic search.

6. Semantic search with vector similarity

Replacing keyword matching with meaning matching. The single biggest upgrade to any search endpoint.

import chromadb

client = chromadb.Client()
collection = client.create_collection("support_docs")

# Index your documents
collection.add(
    documents=[
        "To reset your password, go to Settings > Security",
        "Shipping takes 3-5 business days for standard orders",
        "Refunds are processed within 7 business days"
    ],
    ids=["doc1", "doc2", "doc3"]
)

# Query with natural language
results = collection.query(
    query_texts=["I can't get into my account"],
    n_results=1
)
# Returns "To reset your password..." despite zero keyword overlap

This is where NLP becomes a backend architecture decision, not just a feature. Your search index moves from Elasticsearch keyword matching to vector similarity, and every query suddenly understands synonyms, paraphrases, and natural language without you building synonym dictionaries.

7. Text summarization

Condensing long documents into actionable summaries. Essential for any system that processes documents, emails, or lengthy inputs.

from transformers import pipeline

summarizer = pipeline("summarization", model="facebook/bart-large-cnn")
long_text = """[Your long document text here - meeting transcript, 
               support conversation, legal document]"""
summary = summarizer(long_text, max_length=100, min_length=30)

We use this in our document processing pipelines, a 40-page contract enters the system, the summariser extracts the key terms and obligations, and the structured summary gets stored alongside the original. Humans review the summary. They only open the full document when the summary flags something unusual.

8. Language detection

Identifying the language of incoming text to route it to the right processing pipeline.

from langdetect import detect, detect_langs

text = "Mera order kab aayega? Already 5 days ho gaye"
lang = detect(text)  # 'hi' (Hindi detected)
probs = detect_langs(text)  
# [hi:0.71, en:0.29] code-mixed Hinglish

In multilingual systems, language detection is the first routing decision. Get it wrong and every downstream model receives input in a language it wasn't optimised for. The code-mixed case, Hinglish, Spanglish, is where simple detection fails and you need confidence thresholds to route to specialised pipelines.

9. Text classification

Categorising text into predefined labels. The backbone of automated tagging, content moderation, and document routing.

from transformers import pipeline

classifier = pipeline("text-classification",
                      model="distilbert-base-uncased-finetuned-sst-2-english")

# For custom categories, fine-tune on your domain data:
from datasets import Dataset
from transformers import Trainer, TrainingArguments

train_data = Dataset.from_dict({
    "text": ["server is down", "need invoice copy", "can't login"],
    "label": [0, 1, 2]  # infrastructure, billing, access
})

The zero-shot approach from technique 4 works when you're prototyping. For production with thousands of daily classifications, fine-tuning a small model on your domain data gives better accuracy at lower latency and cost.

10. Keyword and keyphrase extraction

Pulling the most important terms from a document without predefined categories.

from keybert import KeyBERT

model = KeyBERT()
text = """Kubernetes cluster autoscaling failed during peak traffic 
          causing service degradation across three availability zones"""
keywords = model.extract_keywords(text, keyphrase_ngram_range=(1, 3),
                                   stop_words="english", top_n=5)
# [('kubernetes cluster autoscaling', 0.82), 
#  ('peak traffic', 0.65),
#  ('availability zones', 0.61), ...]

We use this to auto-tag incident reports and support tickets. The extracted keyphrases become searchable metadata without anyone manually categorising anything.

11. Retrieval-augmented generation (RAG)

Combining vector search with LLM generation for answers grounded in your actual data. The architecture pattern behind every production knowledge assistant.

import anthropic
import chromadb

# Retrieve relevant context
collection = chromadb.Client().get_collection("docs")
results = collection.query(query_texts=["How to configure SSO?"], n_results=3)
context = "\n".join(results["documents"][0])

# Generate grounded response
client = anthropic.Anthropic()
response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=500,
    messages=[{
        "role": "user",
        "content": f"Based on this context:\n{context}\n\n"
                   f"Answer: How do I configure SSO?"
    }]
)

RAG is the technique that made AI assistants useful for enterprise. Without it, the model makes things up. With it, the model answers from your documentation. The retrieval quality determines the answer quality, invest in your embedding pipeline and chunking strategy before optimising the generation prompt.

12. PII detection and redaction

Finding and masking personally identifiable information before it enters your processing pipeline or logs.

import spacy

nlp = spacy.load("en_core_web_trf")
text = "Contact John Smith at john@example.com or 555-0123"
doc = nlp(text)

redacted = text
for ent in doc.ents:
    if ent.label_ in ["PERSON", "EMAIL", "PHONE"]:
        redacted = redacted.replace(ent.text, f"[{ent.label_}]")
# "Contact [PERSON] at [EMAIL] or [PHONE]"

Run this before any text enters an LLM prompt, a log file, or an analytics pipeline. GDPR compliance on text data starts here.

13. Duplicate and near-duplicate detection

Finding semantically similar content across your dataset. Essential for deduplicating support tickets, detecting repeated questions, and merging similar records.

from sentence_transformers import SentenceTransformer, util

model = SentenceTransformer("all-MiniLM-L6-v2")
existing = model.encode(["How do I cancel my subscription?"])
incoming = model.encode(["I want to stop my monthly plan"])

similarity = util.cos_sim(incoming, existing)
# tensor([[0.84]]) these are near-duplicates
if similarity > 0.8:
    # merge with existing ticket instead of creating new one
    pass

We reduced duplicate support tickets by 34% with this technique. The customer says it differently every time. The embedding says it's the same question.

14. Topic modeling

Discovering the themes across a collection of documents without predefined categories.

from bertopic import BERTopic

documents = [
    "Server response times are increasing",
    "Login page loads slowly since the update",
    "Database queries timing out under load",
    "New feature request for dark mode",
    "Users want mobile app support",
    # ... hundreds more
]
topic_model = BERTopic()
topics, probs = topic_model.fit_transform(documents)
topic_model.get_topic_info()
# Discovers clusters: performance issues, feature requests, etc.

Topic modelling is how you discover what your users are actually talking about without manually reading thousands of documents. Run it monthly on your support tickets and the emerging topics tell you what's broken before the metrics do.

15. Structured data extraction

Pulling structured fields from unstructured text, the bridge between human communication and database records.

import anthropic

client = anthropic.Anthropic()
response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=300,
    messages=[{
        "role": "user",
        "content": """Extract structured data from this text as JSON:
        "Please ship 50 units of SKU-4421 to our Mumbai warehouse 
         by next Friday. Bill to Acme Corp, PO number 78432."

        Fields: quantity, sku, destination, deadline, 
                billing_entity, po_number"""
    }]
)
# {"quantity": 50, "sku": "SKU-4421", "destination": "Mumbai warehouse",
#  "deadline": "next Friday", "billing_entity": "Acme Corp", 
#  "po_number": "78432"}

This is where NLP meets your database schema. Unstructured text in, structured records out. We use this pattern to process invoices, purchase orders, and customer requests that arrive as natural language and need to become rows in a database.

The backend developer's perspective

These fifteen techniques aren't academic exercises. They're the building blocks of modern backend systems that handle natural language, which, in 2026, is most backend systems.

The practical path: start with tokenization and NER for structured data extraction. Add sentiment and intent classification for routing. Implement embeddings and semantic search to replace keyword matching. Layer RAG on top for grounded AI responses. Add PII detection for compliance. Use topic modelling for discovery.

Each technique is a function you add to your pipeline, not a research project you launch. The code snippets above run in production. The libraries are mature. The patterns are proven.

NLP is now core backend infrastructure. For the full landscape of how these techniques are reshaping business operations across fifteen industries, we wrote the comprehensive overview of applications of NLP covering the enterprise deployment patterns and ROI frameworks that product teams need to evaluate before building.

Published by Dextra Labs, AI Consulting and Enterprise Agent Development

GPT-5.6 vs Claude for Building Agents: I Ran the Same Agentic Tasks on Both (Benchmarks + Code)

Dextra Labs — Mon, 24 Aug 2026 05:26:34 +0000

After GPT-5.6 shipped on July 9, we spent two weeks running the same agentic workloads on both models. The stated improvement that interested us most: tool-call refusal rate dropping below 4% on GPT-5.6, down from approximately 12% on GPT-5.5. For production agent systems, that single number matters significantly more than any benchmark leaderboard position.

Claude Sonnet 4.5 had been our default for most agentic work. We wanted to know if that should change.

Short answer: it depends on your task shape. Here's the data.

What We Tested

Three agentic scenarios selected to isolate different failure modes:

Task A: Multi-step tool orchestration A customer service agent that chains four tool calls: order lookup, policy retrieval, refund processing, CRM update. Measures whether the model reliably invokes all required tools in the correct sequence.

Task B: Error recovery mid-workflow Same agent, but with intentional failures injected at tool call 2 and 3. Measures whether the model retries intelligently, produces a meaningful error response, or silently fails.

Task C: Long-context coherence A research synthesis agent operating across 80K tokens of prior conversation context with tool calls interspersed throughout. Measures whether the model loses track of earlier decisions.

We ran 200 trials per task per model. Models tested: GPT-5.6 Terra (the balanced tier at $2.5 input / $15 output per million tokens) and Claude Sonnet 4.5.

Task A: Multi-Step Tool Orchestration

The tool setup is identical for both models. Here's the core loop:

import anthropic
from openai import AsyncOpenAI
import asyncio
from typing import Literal

# Shared tool definitions
TOOLS_CLAUDE = [
    {
        "name": "lookup_order",
        "description": "Retrieve order details and status",
        "input_schema": {
            "type": "object",
            "properties": {
                "order_id": {"type": "string"},
                "customer_id": {"type": "string"}
            },
            "required": ["order_id", "customer_id"]
        }
    },
    {
        "name": "check_refund_policy",
        "description": "Verify whether an order is eligible for refund",
        "input_schema": {
            "type": "object",
            "properties": {
                "order_id": {"type": "string"},
                "order_date": {"type": "string"},
                "customer_tier": {"type": "string"}
            },
            "required": ["order_id", "order_date"]
        }
    },
    {
        "name": "process_refund",
        "description": "Initiate refund for an eligible order",
        "input_schema": {
            "type": "object",
            "properties": {
                "order_id": {"type": "string"},
                "refund_amount": {"type": "number"},
                "reason": {"type": "string"}
            },
            "required": ["order_id", "refund_amount", "reason"]
        }
    },
    {
        "name": "update_crm_record",
        "description": "Log refund action in CRM",
        "input_schema": {
            "type": "object",
            "properties": {
                "customer_id": {"type": "string"},
                "action": {"type": "string"},
                "resolution": {"type": "string"}
            },
            "required": ["customer_id", "action"]
        }
    }
]

async def run_claude(order_id: str, customer_id: str) -> dict:
    client = anthropic.AsyncAnthropic()

    messages = [
        {
            "role": "user",
            "content": f"Process a refund for order {order_id} for customer {customer_id}. "
                      f"Check eligibility, process if eligible, and update the record."
        }
    ]

    tool_calls_made = []

    while True:
        response = await client.messages.create(
            model="claude-sonnet-4-5",
            max_tokens=1024,
            system="You are a customer service agent. Always complete all required steps.",
            tools=TOOLS_CLAUDE,
            messages=messages
        )

        if response.stop_reason == "end_turn":
            break

        if response.stop_reason == "tool_use":
            tool_uses = [b for b in response.content if b.type == "tool_use"]
            tool_calls_made.extend([t.name for t in tool_uses])

            # Add assistant response and tool results to messages
            messages.append({"role": "assistant", "content": response.content})

            tool_results = []
            for tool_use in tool_uses:
                result = await execute_tool(tool_use.name, tool_use.input)
                tool_results.append({
                    "type": "tool_result",
                    "tool_use_id": tool_use.id,
                    "content": str(result)
                })

            messages.append({"role": "user", "content": tool_results})

    return {
        "model": "claude-sonnet-4-5",
        "tools_called": tool_calls_made,
        "complete": set(tool_calls_made) == {"lookup_order", "check_refund_policy", 
                                               "process_refund", "update_crm_record"}
    }

async def run_gpt56(order_id: str, customer_id: str) -> dict:
    client = AsyncOpenAI()

    # Convert Claude tool format to OpenAI format
    messages = [
        {"role": "system", "content": "You are a customer service agent. Complete all required steps."},
        {"role": "user", "content": f"Process refund for order {order_id}, customer {customer_id}."}
    ]

    tool_calls_made = []

    while True:
        response = await client.chat.completions.create(
            model="gpt-5.6-terra",
            messages=messages,
            tools=[convert_to_openai_format(t) for t in TOOLS_CLAUDE],
            tool_choice="auto"
        )

        message = response.choices[0].message

        if message.tool_calls is None:
            break

        messages.append(message)
        tool_calls_made.extend([tc.function.name for tc in message.tool_calls])

        for tool_call in message.tool_calls:
            result = await execute_tool(
                tool_call.function.name, 
                json.loads(tool_call.function.arguments)
            )
            messages.append({
                "role": "tool",
                "tool_call_id": tool_call.id,
                "content": str(result)
            })

    return {
        "model": "gpt-5.6-terra",
        "tools_called": tool_calls_made,
        "complete": set(tool_calls_made) == {"lookup_order", "check_refund_policy",
                                               "process_refund", "update_crm_record"}
    }

Task A Results

Over 200 trials:

GPT-5.6 Terra's improved tool-call reliability is real and measurable. The documented reduction from ~12% refusal rate shows in production results. Claude Sonnet 4.5 costs slightly less per task and responds faster, but dropped tool calls roughly twice as often.

For workflows where every tool call matters, financial operations, order mutations, anything with downstream consequences, the reliability gap has a real cost.

Task B: Error Recovery Mid-Workflow

We injected failures at tool calls 2 and 3 to test recovery behavior. Tool call 2 returns a 503. Tool call 3 returns a malformed JSON response.

async def execute_tool_with_failures(
    tool_name: str, 
    inputs: dict,
    failure_map: dict  # {"check_refund_policy": "503", "process_refund": "malformed"}
) -> str:

    if tool_name in failure_map:
        failure_type = failure_map[tool_name]

        if failure_type == "503":
            return json.dumps({
                "error": "Service temporarily unavailable",
                "code": 503,
                "retry_after": 2
            })

        if failure_type == "malformed":
            return "{{invalid json response}}"  # Intentionally broken

    # Normal execution
    return await execute_tool(tool_name, inputs)

What we looked for: does the model retry intelligently, communicate failure clearly, or silently skip the failed step and continue as if the workflow completed?

Silent continuation is the dangerous failure mode, the agent tells the customer their refund was processed when it wasn't.

Claude Sonnet 4.5 behavior on failures: On the 503, Claude explicitly acknowledged the failure in 91% of cases and either retried or escalated. On the malformed response, Claude surfaced a clear error message in 88% of cases. In approximately 9% of malformed-response cases, Claude produced a response that implied success without confirming the action completed.

GPT-5.6 Terra behavior on failures: On the 503, GPT-5.6 retried or explicitly escalated in 93% of cases. On the malformed JSON, it surfaced a clear error in 91% of cases. Silent continuation rate was approximately 7%.

Neither model is fully reliable without explicit error handling in your orchestration layer. Both need a validation step before reporting success to the user.

Task C: Long-Context Coherence

Context size: 80K tokens of prior conversation history, with 15 tool calls interspersed.

We tested whether each model maintained accurate recall of earlier decisions when making tool calls deep in the conversation.

This is where the context window differences start to matter. Claude Sonnet 4.5 has a 200K window. GPT-5.6 Enterprise has 1.5M. For this test at 80K, both are well within window.

At 80K context, both models performed comparably. Claude maintained earlier decision consistency in 88% of trials. GPT-5.6 Terra maintained consistency in 87%.

The real difference surfaces past 150K tokens of context. That's where Claude's 200K window becomes a constraint and GPT-5.6's 1.5M window stops being theoretical.

For most enterprise agent tasks, customer service, sales automation, operational workflows, 80K is ample. The 1.5M window advantage is meaningful for legal document review, large codebase analysis, and compliance audit workloads.

Summary: When to Use Which

Based on 600 trials across three task types:

GPT-5.6 Terra / Sol for:

Complex multi-step tool chains where reliability at each step matters
Workflows that will eventually scale to 200K+ context
Teams already using OpenAI infrastructure who can benefit from Luna/Terra/Sol tier routing
New agent projects where native multi-agent orchestration reduces custom code

Claude Sonnet 4.5 for:

Existing production deployments with validated integration patterns, rebuilding for marginal reliability gain isn't worth it
Latency-sensitive workflows where first-token speed matters
Cost-optimized high-volume deployments on standard enterprise workloads
Teams that have invested in Claude-specific prompt engineering and safety tuning

Routing approach: The best production architecture we've landed on doesn't pick one. It routes by task complexity: lightweight queries to Claude Haiku or GPT-5.6 Luna, standard agent tasks to Claude Sonnet 4.5 or Terra, and architecture-level reasoning to Claude Opus or GPT-5.6 Sol.

async def route_by_complexity(task: AgentTask) -> str:
    if task.estimated_tokens < 2000 and task.tool_calls_required < 2:
        return "claude-haiku-4-5"          # Fast, cheap

    if task.tool_calls_required >= 5 or task.context_size > 100_000:
        return "claude-opus-4-5"           # Complex reasoning

    if task.requires_document_analysis and task.context_size > 180_000:
        return "gpt-5.6-sol"               # Large context

    # Default: either works, pick by cost
    return "claude-sonnet-4-5"            # Slight cost advantage at scale

The Number That Actually Matters

Tool-call reliability is the metric that determines whether your agent works in production. At 4% failure rate versus 12%, the difference in a 10-step workflow compounds:

At 4% per-step failure: 66% chance of full workflow completion (0.96^10)
At 12% per-step failure: 28% chance of full workflow completion (0.88^10)

GPT-5.6's documented improvement on this metric is the reason it's worth evaluating seriously for new complex agent builds.

But models aren't the whole story. The tool definitions, the error handling, the orchestration logic, and the recovery patterns account for as much variance in production reliability as model choice. We've seen well-architected Claude deployments outperform poorly-architected GPT-5.6 setups on every metric that matters.

Model choice depends on your task shape. For teams building production agents, working with specialists shortcuts months of trial and error. Top ChatGPT development companies and the teams building on both APIs:

Top ChatGPT Development Companies

Dextra Labs builds production AI agent systems for enterprise clients. We work across both OpenAI and Anthropic APIs, the right model depends on the task, not the marketing. hello@dextralabs.com