AI-First Product Architecture
Let customers use their own AI with your product.
An Agent Gateway lets Claude, ChatGPT, Siri, Gemini, and approved third-party agents access your product safely, with consent, scoped permissions, audit logs, and your business rules intact.
Built for mobile apps, service platforms, customer accounts, and AI-first product systems.
In plain English
An Agent Gateway is the safe front door for AI assistants. It decides what an agent may read, what it may request, what needs user approval, and what gets logged, so customer AI, partner agents, voice assistants, and your own app can all use the same product capabilities with consent, scoped permissions, business rules, and audit.
Why this matters now
Customers are no longer using only your app, your website or your support channel. They are starting to use their own AI assistants to understand information, compare options, automate tasks and manage services, and that changes the interface between your product and the customer.
If your product cannot safely expose actions and data to agents, customers will work around you: screenshots, scraping, shared credentials, copy-paste, or third-party tools you cannot control.
Customers brought their own AI
Claude, ChatGPT, Gemini, Siri and on-device assistants are becoming daily tools. Customers increasingly expect to ask their assistant about the products and services they use.
Agent protocols are becoming practical
MCP (the Model Context Protocol) is becoming an important integration layer, a way to expose product capabilities to AI clients without building a separate integration for every assistant.
Voice and OS-level actions are real surfaces
App Intents on iOS and App Actions on Android let assistants trigger real product actions, not just open an app.
Delaying agent access is a product decision, not a neutral default.
The outcomes we deliver
Three concrete things your customers can do once an Agent Gateway is in place.
“Hey Claude, what’s going on with my account?”
Customers ask their own AI assistant and get a real, current answer pulled from your product, not a scraped screenshot, not a chatbot guessing from your help center. The actual data, with the right scopes, consent and audit trail.
Business outcome: You stop competing with the customer’s AI and start becoming a tool inside it.
“Switch me to the cheaper plan when it’s actually better for me.”
Third-party agents and comparison tools act on the customer’s behalf, because the customer gave explicit permission. No shared passwords, no scraping. The system stores a delegation record (this agent, these scopes, this duration, this user, this audit trail), revocable any time.
Business outcome: Retention improves: the customer’s tools work inside your product, not around it. A comparison tool no longer has to pull customers away; it can work through your product, with permission.
“Tell me before I overpay.”
Your own proactive agents detect billing anomalies, usage spikes, plan mismatches or renewal moments, and notify the customer, explain what is happening and propose a safe action. The user stays in control.
Business outcome: The support call that did not happen. The complaint that never reached an app-store review. The renewal that took care of itself.
What changes for the customer
| Today | With an Agent Gateway |
|---|---|
| I open the app, log in and click through three screens to see what is left on my plan. | I just ask my AI. It already knows what it is allowed to know. |
| I’d use a comparison site, but I’m not sharing my password. | I gave the comparison site read-only access to my usage for 90 days. Then it expired. |
| I only find out about the surprise charge when I open the bill. | My provider warned me early and asked if I wanted to block the risky option. I tapped yes. |
| Siri cannot actually do anything useful with my account. | “Siri, top up my prepaid by twenty euros.” Done, confirm with Face ID. |
| Every new AI feature feels like a separate project. | The same action registry powers the app, agents, partners and voice. |
The customer experience changes from opening your interface to authorizing useful actions.
External example: conversational finance
Want to explore what it could feel like to interact with financial data in a more conversational way?
simplebanking is an independent beta experiment that shows where lightweight, AI-assisted personal finance interfaces may be heading.
It is not an M-Squad project, but it is a useful example of the broader shift: customers want faster, more natural access to their data.
What an Agent Gateway is
An Agent Gateway is the safe action layer between your product and the agents that want to use it. It defines:
- what agents can read
- what agents can request
- what requires user approval
- what is logged
- what can be revoked
- which scopes exist
- which business rules apply
- which protocol surfaces expose the capabilities
It is not just an API gateway. A conventional API gateway routes traffic, manages rate limits and protects infrastructure. An Agent Gateway manages delegated action.
API gateways protect systems. Agent Gateways protect delegated user action.
The Agent Gateway, in one glance
A single action layer in front of your existing systems. Many surfaces. One consent model. One audit trail. One action registry.
Additive
The gateway sits on top of what you already have. The goal is not to rewrite your core system, it is to expose useful actions safely.
Identity-aware
If you already use OAuth or OpenID Connect, the gateway extends that model with finer scopes, agent clients, delegation records and revocation.
Safe by default
Read actions can execute directly when authorized. Write actions generate a plan the user approves, no unilateral authority over sensitive actions.
Protocol-flexible
MCP is one surface. REST is another. App Intents and App Actions are others. The durable layer underneath is the action registry.
The durable layer: the action registry
Models will change. Assistants will change. Protocols will change. The durable part is the action registry, the product contract agents can trust:
get_account_summarycheck_usagecheck_costestimate_next_billcheck_next_billing_datesummarize_recent_activitycompare_plansrequest_plan_changemake_paymentopen_support_case
Each action has required scopes, input and output schemas, a risk level, approval requirements, business rules, audit behavior and fallback behavior.
MCP is one rendering. The action registry is the product contract.
How we get there
1Foundation
6–10 weeks
Review existing APIs, auth and workflows. Define the first action registry, the consent and delegation model and audit logging. Expose read-only REST actions for your own app and web; flag high-risk actions that need a plan/approve flow.
Outcome: A clean, auditable action layer your own product team can build against.
2Customer AI & internal agents
4–8 weeks
Generate the first MCP surface and connect a real AI client (e.g. Claude Desktop) to live product actions. Add one internal proactive agent, a plan/approve flow for selected writes, and revocation, expiry and audit views.
Outcome: A customer can use their own AI with your product, and your own agent can act, with consent.
3Partners & voice
6–10 weeks
Open selected actions to approved partners with onboarding, docs and per-scope delegation. Connect App Intents (iOS) and App Actions (Android) so voice routes through the same gateway. Harden rate limits, monitoring and partner audits.
Outcome: The Agent Gateway becomes a product surface in its own right.
Where this came from: an operator prototype
We designed and prototyped an Agent Gateway as part of a mobile-app relaunch evaluation for a German mobile operator with around 3 million app customers. The brief was not “build a chatbot”, it was “what makes the next app a platform, not just a rewrite?”
What the prototype proved:
- A mobile app can use the same gateway as external agents, the Flutter app talked to its backend through the gateway, the same way an external agent would.
- MCP can expose real customer actions: a customer could ask an AI client a product question and the answer came from the same backend code path that served the in-app assistant. The AI did not guess, it asked the product.
- Proactive agents fit the same model: usage checks, billing-anomaly detection and optimization agents all run through the same consent, delegation and audit model.
- Voice becomes another surface, not another architecture: Siri, Google Assistant and Gemini route through App Intents and App Actions into the same gateway.
Built in four days, by one engineer with AI-assisted development (how we build with AI), the gateway forced the right upstream questions early: what scopes should third parties have, which actions require approval, how consent is revoked, how long delegation lasts, what the audit log must prove, and what happens when an agent fails.
The gateway is not a chatbot feature. It is product infrastructure for the agent era.
When an Agent Gateway makes sense
Strong fits
Products with customer accounts, authenticated workflows and meaningful user-specific actions:
- Telecom & utilities
- Banking & insurance
- Mobility & travel, healthcare services
- Subscription businesses & marketplaces
- B2B SaaS, customer portals, logistics / field service
Weak fits
An Agent Gateway may be overkill if the product is mostly:
- Public content or anonymous browsing
- Simple lead generation
- Static marketing pages
- One-off prototypes
- Anything without meaningful user-specific actions
Engagement options
Readiness Audit
~2 weeks
- Readiness assessment
- First action map
- Risk & constraint review
- Recommended Phase 1 scope
- Roadmap + rough effort estimate
Best for: Teams that know AI agents matter but are not sure where to start.
Pilot
8–12 weeks
- Action registry + consent model
- Audit logging
- Read-only product actions
- First MCP surface
- One demonstrable AI-client flow
- One plan/approve write flow, if apt
Best for: Teams that need a working executive demo and a real technical foundation.
Program
3–6 months
- Full Phase 1–3 delivery
- Partner-facing access model
- App Intents / App Actions + voice
- Internal proactive agents
- Docs, monitoring, handover
Best for: Teams that want agent access as a long-term product capability.
Related: AI agents, product systems, mobile app technology and AI-assisted engineering.
Your customers are already using AI
Make sure they can use it with you, not around you. A 30-minute call usually clarifies whether you need an Agent Gateway, what shape it should take, and where the cheapest useful first step lives.
Common questions
Do we need this if we don’t have an AI strategy yet?
Possibly, yes. The Agent Gateway is often the practical foundation of the AI strategy, it defines what AI can safely do with your product. Without it, teams build isolated AI features that later need consolidating.
Is this just an API gateway with extra steps?
No. A conventional API gateway focuses on routing, rate limits, authentication and infrastructure. An Agent Gateway adds delegated user action, per-scope consent, approval flows for writes, audit trails, revocation, agent-facing surfaces (MCP) and business-rule enforcement for autonomous or semi-autonomous actions. Different problem, different shape.
What if MCP changes or gets replaced?
The action registry is the durable artifact; MCP is one rendering of it. A well-designed gateway makes protocol surfaces generated or replaceable, not hand-built into the core.
Can we start small?
Yes. A useful first step is a REST surface + consent model + audit log + read-only actions, no external agents, no voice, no public MCP surface. That alone often clarifies the API and permission model.
Do agents get write access?
Not directly by default. For sensitive actions the pattern is: the agent proposes, the system creates a plan, the user approves, the gateway executes, and everything is logged. This keeps the user in control.
Does this replace the mobile app?
No, it makes the app more important. The app becomes the trust anchor: where customers authenticate, approve sensitive actions, manage delegations, review audit trails and recover from edge cases.