Malte Kosub

Most companies are still missing out on what’s happening in customer experience right now. 1. Personal AI agents will drive huge new volumes 2. AI in customer experience will become a revenue driver 3. Agents will start improving themselves These shifts are already changing the industry. Companies need to get ready for them now.

Personal sites will help agents find you. The more interesting part is agents that can actually do things for you once they have the context. Just the last 48 hours for personal AI agents: - Quest builds a detailed profile of you and acts inside your apps - Meta’s Muse can now talk live - Perplexity’s Teammates take on ongoing work and collaborate with each other - Living Brain gives agents persistent shared memory across ChatGPT, Claude, Cursor and others - Claude can now read connected bank accounts and spot rising bills Soon your agent notices the internet bill went up €20, remembers you’ve complained about the provider before, and (with one tap) sends the renegotiation email or the cancellation threat. Most people see the increase, get annoyed, and do nothing. That gap is about to close.

Whenever someone launches a new voice agent demo, they make it look easy. Here’s what it actually takes to build one that’s ready for production: - detect speech without cutting off words - handle callers who interrupt mid-sentence - stop speaking when the caller starts talking - resume naturally after an interruption - recognize when a caller is thinking rather than finished - handle long pauses without hanging up - ignore background conversations when appropriate - handle traffic noise, music and poor microphones - recognize speech over unstable mobile connections - handle regional accents and dialects - recognize mixed-language names and addresses - recognize spoken numbers, dates and currencies - confirm ambiguous account and booking references - spell back names and identifiers accurately - pronounce customer names and brand names correctly - handle acronyms and product-specific terminology - avoid reading URLs and long numbers unnaturally - choose when to speak versus send an SMS or link - keep the time to first response low - measure end-to-end latency rather than model latency alone - account for latency from telephony, tools and synthesis - handle slow tool calls without awkward silence - handle callers who change their mind halfway through - recover when the model mishears a request - ask for clarification without looping - handle angry, distressed or confused callers appropriately - make the agent's identity clear when required - make disclosures before recording where required - end calls cleanly and at the right time - pick the first use case based on volume and complexity - map the real customer journey before writing a prompt - identify which outcomes the agent can actually complete - break complex tasks into safe, testable steps - define the agent's skills and permitted actions - set the persona, tone and level of formality - write the first prompt - version the instructions as the agent changes - separate business rules from conversational style - specify what the agent must never promise - know when to ask a follow-up question - know when to stop asking questions - track context across turns in the same conversation - handle corrections to information already provided - keep important context when conversations get long - avoid inventing facts when information is missing - handle conflicting information from different sources - know when to use a tool instead of answering from memory - select the right tool for each requested action - supply the right parameters to each tool - check tool outputs before using them in an answer - handle tool timeouts and partial results - avoid repeating a charge or cancellation after a retry - require confirmation before irreversible actions - handle multi-step workflows that cross systems - keep track of what has and has not completed - recover from partial workflow failures - know when a human must take over - pass the reason and context with a human transfer - avoid claiming an action succeeded before confirmation - explain next steps when an action cannot be completed - collect FAQs, policies, process maps and product documents - identify which documents are outdated or contradictory - assign owners to the knowledge sources - remove formatting that makes sense only on a screen - split complex policies into usable decision rules - keep policy exceptions and eligibility conditions intact - make knowledge searchable by the agent - retrieve the right information for the current request - filter retrieved knowledge by customer, product and region - respect permissions when retrieving internal content - handle multiple versions of the same policy - track when a source was last updated - show where a factual answer came from internally - know when the knowledge base has no answer - avoid answering from an obsolete policy - update knowledge when a process changes - validate that knowledge updates do not break existing flows - connect live customer data to static knowledge - use order, account and service history only when relevant - minimize sensitive data sent to models - set rules for how long conversational context is retained - remove stale context when it should no longer be used - find every system involved in a single customer request - map CRM, billing, ticketing, booking and order systems - find out which systems have usable APIs - verify that API documentation matches production behavior - get realistic sandbox accounts and test data - obtain credentials through approved channels - rotate credentials without interrupting active service - allowlist integration traffic where required - agree on API rate limits with system owners - handle authentication and token expiry - map inconsistent customer IDs across systems - normalize data formats between systems - validate inputs before calling an API - validate responses before speaking them aloud - handle empty, malformed and contradictory API responses - retry transient failures with backoff - avoid retrying non-idempotent actions blindly - use idempotency keys where supported - handle duplicate events and delayed responses - handle pagination for large records - avoid exposing raw internal errors to callers - build an integration layer when a system has no suitable API - keep test and production endpoints separate - monitor API health and error rates - handle maintenance windows in downstream systems - track which backend action caused a failed conversation - write relevant outcomes back to systems of record - reconcile a conversation outcome with the backend record - keep an audit trail of important actions - protect webhook endpoints and verify signatures - retry failed webhooks and inspect delivery attempts - account for systems that update asynchronously - handle a backend that succeeds after the caller hangs up - choose and integrate the telephony provider - connect numbers, trunks and routing rules - handle inbound call routing and transfers - support warm transfers when the use case needs them - pass caller context to the receiving human agent - handle transfers outside business hours - route by language, region or customer segment - preserve caller identification where permitted - handle hidden or unavailable caller IDs - manage call recording and consent requirements - manage DTMF input when needed - avoid transferring callers into dead ends - manage queueing and capacity limits - handle carrier outages and alternate routes - handle calls dropped during a transaction - avoid losing the case when the call disconnects - ensure outbound calling follows applicable rules - route urgent situations straight to a human - measure the full call experience across providers - load-test with realistic concurrent calls - measure performance at peak traffic rather than average traffic - model traffic spikes after campaigns or outages - set concurrency limits that protect downstream systems - reserve enough compute and provider capacity - monitor saturation across model, speech and API services - set timeouts for every external dependency - use circuit breakers when dependencies degrade - choose safe fallback behavior when a provider is unavailable - fail over without duplicating customer actions - plan for regional service interruptions - select deployment regions for latency and data residency - understand which dependencies remain single points of failure - measure uptime from the caller's perspective - set service-level objectives and error budgets - set recovery time and recovery point objectives where relevant - run disaster recovery exercises - plan for model provider incidents - plan for speech provider incidents - plan for telephony carrier incidents - handle a surge in human handoffs - isolate noisy workloads and rate-limit abuse - make infrastructure changes without dropping active calls - roll out changes progressively by traffic percentage - roll back quickly when quality drops - keep a tested previous configuration available - avoid configuration drift across regions - monitor costs per minute and per resolved conversation - forecast capacity and provider spend - track unit economics as call volumes grow - authenticate callers to the level required by the action - agree on identity verification with fraud and security teams - separate identity verification from authorization - check permissions before exposing account information - check permissions again before changing an account - apply least privilege to tools and service accounts - restrict which tools each agent can call - prevent prompt injection through retrieved documents - prevent malicious instructions in tool responses - test attempts to bypass policy with adversarial prompts - block unsafe or unauthorized transactions - require human approval for designated high-risk actions - redact sensitive information from logs where appropriate - manage secrets without embedding them in prompts - rotate and revoke secrets and access tokens - support enterprise identity and access management requirements - control who can edit prompts, tools and deployment settings - record who approved and published a change - maintain audit logs with appropriate access controls - set data retention and deletion rules - implement regional data handling requirements - assess subprocessors and model-provider data policies - complete security and privacy reviews before launch - assess applicable GDPR obligations - assess applicable EU AI Act obligations and timelines - review sector-specific obligations where relevant - run penetration tests and security assessments - establish incident response and breach escalation procedures - train staff who administer or supervise the agents - define success criteria before building the demo - create representative test conversations - include frequent, rare and high-risk intents - use synthetic data that covers realistic edge cases - separate test data from real customer data - simulate callers who interrupt or contradict themselves - simulate callers who provide incomplete information - simulate callers who change their request mid-call - simulate abusive and manipulative prompts - test different accents, languages and audio conditions - test noisy lines and overlapping speech - test incorrect account numbers and missing records - test API errors, timeouts and inconsistent responses - test that tools are called in the right sequence - test that tool parameters are correct - test that prohibited actions remain blocked - test authentication and authorization boundaries - test escalations and human handoffs end to end - test what happens when no human is available - test a call that disconnects halfway through an action - run regression tests before every release - compare performance across prompt and model versions - re-test when a model provider updates a model - re-test when speech or telephony providers change - re-test when business policies change - check that improvements do not break existing use cases - combine automated evaluations with human review - calibrate AI-based judges against human ratings - track false positives and false negatives in evaluations - review evaluation failures and fix their root causes - measure task completion rather than plausible-sounding replies - measure resolution separately from containment - measure latency, interruptions and transfer quality - monitor conversation quality by language and use case - inspect samples of successful and unsuccessful calls - check compliance and safety outcomes continuously - keep an auditable record of release evaluations - log conversation events with appropriate privacy controls - trace each request across speech, model and backend services - link tool calls to the conversation that triggered them - monitor live error rates and degraded dependencies - monitor latency at every stage of a call - identify where callers abandon conversations - measure repeat contacts after apparent resolution - measure customer sentiment where it is useful and valid - identify conversations that end without an outcome - flag failed or incomplete backend transactions - spot unexpected changes in intent distribution - spot anomalies before customers report them - compare performance across regions and languages - compare cohorts before and after a release - monitor cost, usage and concurrency by customer - alert the right on-call team when thresholds are crossed - make alerts actionable instead of generating noise - replay or inspect failed cases safely - turn production failures into new test cases - maintain a queue of improvements by impact - identify knowledge gaps from real conversations - track whether fixes actually improve outcomes - export appropriate data to the enterprise analytics stack - build dashboards for CX, IT, operations and compliance - review agent performance on a regular cadence - identify the executive sponsor and operational owner - align IT, security, legal, the contact center and business teams - agree on the use case and scope of the first pilot - establish a baseline before the pilot starts - agree on resolution, quality, safety and cost KPIs - set minimum acceptance criteria for production - assign owners to prompts, integrations and knowledge - assign owners to downstream systems and API contracts - secure access to test environments early - complete procurement and vendor risk reviews - agree on support hours and escalation paths - train contact-center agents receiving transfers - prepare supervisors to review AI conversations - communicate changes to frontline teams - set up a test number and internal pilot - run a limited external pilot with monitored traffic - compare pilot results against the agreed baseline - expand traffic in controlled stages - check readiness separately for each region and language - plan local regulatory and business-policy variations - prepare a go-live runbook and rollback plan - name who gets called when something breaks on launch day - agree on incident severity and response responsibilities - set a process for urgent business-rule updates - set change approval and release ownership - review quality after each rollout stage - plan maintenance and ownership after launch - budget for ongoing monitoring, evaluations and updates - revisit KPIs as use cases and call volumes expand - keep improving the agent after the first successful launch - … And that’s before we get into customizing the enterprise company’s tech stack. The demo is the easy part. After that, the real fun begins.

I hear some people questioning the ROI of AI in large enterprises. I don’t think AI is the problem. It’s how companies use it. Imagine a colleague telling you AI hasn’t changed how they work. Then you find out they only use ChatGPT to write better emails and as a smarter Google Search. Of course it hasn’t changed much. Real productivity gains happen when you connect AI to your systems, give it context, and rethink how you work from the ground up. The same is true for enterprises. Companies should stop measuring AI transformation by how many employees use ChatGPT, Copilot, or Claude daily. Instead, measure how much context AI can access, how many systems it’s connected to, and how many workflows autonomous agents execute from start to finish. Don’t measure how much AI your employees use. Measure how much work AI actually gets done.

I think most companies blocking AI agents today will end up regretting that decision. @tobi put it well on @alexeheath's podcast: go back to problem-solving mode. Companies need to think in first principles again instead of building higher walls. Amazon blocks agents because it has an ads business to protect. But ads only make money while a human looks at the page. Agents don’t look. I rebooked a missed chair delivery with Instinct. One 25-second voice note, then the agent did 8 back-and-forths with the company. 30 seconds of my time instead of 20 minutes. Customers won’t want to do that themselves again. Blocking is a short-term fix.

Trust your first principles over "that's how it's always been done." One of the biggest lessons I've learned building Parloa. There have been quite a few times when we trusted conventional wisdom, only to eventually go back to first principles. Sometimes at the cost of a lot of time and money. Especially in AI, where the world is changing so dramatically, experience can be misleading. What worked five years ago might be completely wrong tomorrow. Don't let the old playbook define how you build your company. The right playbook might look completely different. Trust your first principles first. If they align with experience, great. But never the other way around.

The new customer service desk already looks like this: A personal AI agent for every customer on top, with the full context underneath: past orders, sizes, open bookings, latest conversations, etc. Serving customers well means knowing them. Every customer needing a human who knows the full context isn’t economically scalable in the same way. With AI, that one-to-one relationship becomes possible at a completely different scale. The context layer is the customer relationship now. Every channel will plug into it.

Very excited to announce our next milestone with SAP! We’ve been selected as SAP’s exclusive Solution Extension for conversational AI agent management, a designation fewer than 2% of partner-built offerings in the SAP Store receive. SAP will now sell and support Parloa globally. Incredible to see how far we’ve come together!

One of the biggest mistakes founders make is setting “reasonable” goals. Building businesses is about chasing what you believe in, even if it sounds impossible and even if it’s never been done before. There’s no better signal to keep going than people calling you crazy.

Companies use the term FDE (Forward Deployed Engineer) for two quite different roles that a lot of people misunderstand. It gets treated as the golden weapon to destroy any problem, but what’s missed is that it’s actually split into two different jobs. In my view, FDEs fall into two categories: - Type 1 FDEs build 80-90% of the solution with each customer. - Type 2 FDEs work on top of a product that already delivers most of the value, and bridge the last mile by connecting the backends and setting up the customer’s logic inside the platform. This matters for two reasons, it tells you: 1. Whether you’re building a product or a service business 2. Who you specifically need to hire, because each type needs a different profile. We wanted one platform where customers could build their own agents on top of it. That is a Type 2 model. A bunch of smart founders are hiring FDEs right now. But it’s important to know which type you’re hiring: Ask yourself how much of the solution exists before the FDE shows up. If the product already delivers most of it, it’s a Type 2. If the FDE builds most of it with the customer, it’s a Type 1. That decides how you build the product and which salespeople & FDEs you hire.

If anyone can build an agent, your edge is… - Deterministic boundaries on critical actions - Only the right context at the right moment - Guardrails that hold under pressure - Evals that define good before you ship - Successful agent-to-agent interactions - Authentication when calls are agent-to-agent - Dedicated capacity so latency holds at peak - Observability once agents are loose in production

Companies blocking AI agents is pretty understandable right now. Delta is blocking agents from booking flights. Yelp is charging for access to its data. Others are restricting automated access to their websites. I think companies have two options going forward: Option 1: Keep blocking agents. You protect your data, ad revenue and for the time being direct customer relationships. But as personal agents become more common, customers may move to services their agents can actually use. Option 2: Find a safe way to let agents in. Middleware verifies who they represent, what they’re allowed to do, and makes sure they follow your internal processes. This is what we have built and offer to our customers. I think companies that don’t start building on agent middleware now are setting themselves up for a competitive disadvantage.