Published 2026-07-15 · Updated 2026-07-23

How I Turned an Email Agent Into an AI Layer for an Entire Online Business

A production case study: an email agent, several RAG collections, FAPI, Stripe, MioWeb and MCP servers over a single continuously updated data layer.

I didn’t start with a vision that chat would one day replace every application. I started with a concrete problem faced by a client who sells online video courses.

The client receives a large volume of emails. People ask which course is right for them, what exactly the current offer includes, where to find their access, or why they can’t log in to the members’ area. On top of that, prices and promotions change, new products appear, and some of the offers belong to partners the client works with — for example on dietary supplements.

The right answer is therefore not just a nicely written piece of text. It has to take into account the current product, a specific customer’s payment, access to the members’ area, business rules, and content the client has already published.

I built and deployed a system that ties this information together. First I built an email agent that prepares draft replies. But over time I realized that its most valuable part isn’t the email generation itself. It’s the layer of up-to-date knowledge, integrations, and safely scoped tools beneath it.

Today that same layer is used not only by the email agent, but also by private MCP servers and a support chatbot on the website.

The first production use case: an email agent

When a new email arrives, the agent first determines what the person actually needs. Depending on the type of question, it doesn’t reach for a single universal prompt but selects the right sources.

If a customer has a login problem, the agent can verify:

who the customer is and under which email they purchased;
which orders and invoices they have in the billing system;
whether the payment went through via Stripe;
which courses they actually paid for;
which part of the website and members’ area they should have access to in MioWeb;
what the correct procedure is for restoring or fixing access.

From these facts it prepares a draft reply directly into the email. Nothing is sent automatically. A person reviews the draft, edits it if needed, and only then sends it.

For a product question the approach is different. The agent searches the current course descriptions, offer rules, prices, bonuses, and ongoing promotions. When someone isn’t ready to commit to a paid product yet, it can first recommend a relevant article or a specific free video.

This is no longer an experiment over a handful of sample documents. The system is deployed in real operation, works with live queries, and has to handle the mess that usually isn’t present in a demo: different email addresses, multiple purchases, old offers, partner products, price changes, and incompletely phrased questions.

It’s actually not a single RAG database

At the start it would be tempting to load everything into one vector database and let the model figure it out. But once deployed, it quickly becomes clear that different types of knowledge have different authority, a different way of being updated, and a different purpose.

That’s why I split the content into separate collections.

1. Products, offers, and business rules

The first collection contains product information from the website and relevant content from Facebook: course descriptions, prices, bonuses, ongoing promotions, the rules of individual offers, and information about partner products.

This is the source for questions such as:

“What does this course include?”
“Is the discount still valid?”
“Is the product suitable for a beginner too?”
“Which bonuses do I get with this variant?”

This collection has to be updated continuously. A price or promotion that was valid last month must not be used today just because it has high similarity to the query.

2. Blog articles

The second collection contains articles the client has written. It serves not only the email agent, but also the creation of new content.

The client can ask what they have already published on a topic, which arguments they used, or which older texts a new article would needlessly repeat. The same source helps the agent recommend useful free content first, instead of immediately selling a course.

3. Videos and their transcripts

The third collection contains videos, metadata, and transcripts. Thanks to this the system doesn’t search only by video title, but by what was actually said in it.

The agent can recommend a video matching a specific problem and, ideally, link directly to the relevant passage. That’s far more useful than sending someone a generic list of ten videos and leaving them to find the right answer themselves.

RAG isn’t a database I fill once

The most important part of the system isn’t the embedding model. It’s the update process.

The website changes, articles are added, new offers appear on Facebook, videos get new transcripts, and old products cease to be current. Each record therefore needs to be tied to its original source, content type, the time of its last change, and a stable identifier.

Where possible, a webhook captures the change. Alongside that, a regular synchronization runs that compares the source with the content in the index. It reprocesses changed items, adds new ones, and marks removed or invalid ones so the agent doesn’t use them as current truth.

Production RAG for me isn’t a pile of text converted into vectors. It’s a managed knowledge layer for which I can answer:

where the information came from;
when it was last verified;
whether it’s a current offer or historical content;
which system is authoritative for that type of information.

Some data doesn’t belong in RAG at all

RAG is good for content and knowledge. It’s not suitable as a source of truth for the current state of a payment, invoice, or a user’s access.

The agent finds out this information only at the moment of the query, via APIs:

FAPI for orders, invoices, and accounting operations;
Stripe for the state of payments and transactions;
WordPress and MioWeb for website content, accounts, and access to the members’ area.

The difference is fundamental. A general question — “what does the course include?” — can go to the knowledge collection. The question “did this person pay for the course and should they have access?” has to go to a live system.

The agent then composes the answer from both layers. RAG tells it how the product works and what the correct procedure is. The API tells it what actually happened to a specific customer.

The email agent became reusable infrastructure

When the email agent started working, it dawned on me that I hadn’t built just an inbox automation. I already had most of the hard work done:

up-to-date knowledge collections;
connectors into FAPI, Stripe, WordPress, and MioWeb;
rules for which source takes precedence;
tools with precisely defined inputs and outputs;
authentication, auditing, and control over risky actions.

It would be a shame to lock this infrastructure inside a single workflow. That’s why I built remote MCP servers over selected parts of it, running on a Hetzner VPS.

The Model Context Protocol makes it possible to offer data and operations to various AI clients through a shared interface. The client doesn’t have to learn FAPI’s internal structure or know where the video archive is stored. It only sees specific tools, for example:

find a customer’s invoices;
verify a duplicate payment;
prepare an invoice cancellation;
find out purchased courses and available access;
search for articles on a topic;
recommend a relevant video;
compare a new text with previously published content.

Access to the server is protected by a standard OAuth/OIDC flow. Each client and user gets only the permissions they need. A tool for working with content doesn’t have to be able to cancel an invoice, and a public chatbot has no reason to see customer orders.

FAPI operated through conversation

One of the practical results is the ability to work with FAPI from a chat client.

Instead of clicking through the admin interface, the client can ask:

Find the customer by email, check whether they paid twice, and prepare a cancellation of the duplicate invoice.

The MCP server calls precisely scoped operations over FAPI, returns the documents found, and prepares the next step. A write action isn’t a general access to the API. It has its own validation, an audit record, protection against double execution, and requires confirmation before an actual cancellation.

For me this is an important difference between chat hooked up to data and a system that can be used safely. The model doesn’t decide what arbitrary HTTP request to send. It chooses from a small set of operations whose behavior I defined in advance.

The same data, more interfaces

Today more inputs run over the same infrastructure.

A content assistant in ChatGPT

When writing a new article, the client can ask what they’ve already written on the topic, which video fits it, or whether the new text conflicts with the current offer. The MCP server uses the same collections of articles and videos as the email agent.

No additional copy of the knowledge is created that would have to be maintained separately. What changes is the interface and permissions, not the source of truth.

On the website there’s a support chat that, via a FastAPI server, calls a selected knowledge collection. A visitor can ask a question in plain language and get an answer based on the current content.

The public widget naturally has a different set of options than the private email or accounting agent. It can work with product information and recommend content, but it doesn’t get access to invoices or to other customers’ data.

A laptop, phone, or another AI interface

The main advantage of a separate MCP and API layer is that I’m not dependent on a single application or a single device. I can connect to the same capabilities from a laptop, from a web chat, or from a phone — depending on what a particular client currently supports.

The business logic doesn’t run on the laptop. It runs on the server. The device is just the input interface, so I don’t have to solve integrations into FAPI, Stripe, or the database again on each of them.

What runs today and what the next step is

Today the system can read emails, search in separate knowledge collections, verify live data in connected services, and prepare draft replies. Selected internal functions are also available via remote MCP servers, and the public portion of the knowledge via the support widget.

The next step isn’t to add another chat bubble. I want to improve the way results are displayed.

I have, for example, a tool connected to web analytics and advertising systems. To the question “how did the ads perform this month?” it can today return data and a written summary. But a more natural response would be an interactive chart with a date-range filter and the ability to drill into a specific campaign.

Similarly, for an invoice I don’t always want just a text listing. A preview of the document, or a form with a clearly marked change before confirmation, may be more useful. For a recommended video it would make sense to have a player open right at the relevant timestamp.

MCP Apps: when chat needs a chart, a form, or a preview

Since January 2026, MCP Apps have been an official extension of the protocol. An MCP tool no longer has to return only text or structured data. It can supply an interactive user interface that a supporting client displays directly in the conversation.

For my system this opens up several concrete possibilities:

a chart of sales, traffic, or ad performance;
an invoice preview before cancellation;
a form for checking data before a write;
a video player opened at the relevant passage;
a dashboard combining data from multiple systems;
a multi-step approval of a sensitive operation.

Conversation therefore doesn’t have to remove the graphical interface. It can assemble it according to the current intent. When the best answer is a sentence, it returns a sentence. When a chart, document, or form is better, it displays the right component.

Support isn’t yet the same across all clients and all devices. The OpenAI documentation on developer mode and MCP Apps states, as of July 2026, that full MCP support including write actions is being rolled out in beta mode for ChatGPT Business, Enterprise, and Edu. MCP Apps are available in ChatGPT on the web, not in the mobile app; Pro users can connect their own MCP in developer mode for reading and search, but not for full write actions.

That’s why I keep the long-term architecture separate from the momentary limitations of a specific client. The MCP server, RAG collections, and integration layer can stay the same. On top of them, ChatGPT, a custom MCP client, a web widget, or another interface can change.

If support in the clients I use is sufficient, I’ll build the visual outputs as MCP Apps. If not, a custom client can display the same data. The important thing is that the analytics, permissions, and business logic already exist on the server and I don’t have to build them again.

Security isn’t a property of the protocol

MCP standardizes how a client discovers and calls a tool. By itself, however, it doesn’t guarantee that the tool is safe.

That’s why in the system I separate public and internal data, reads and writes, and the individual roles. A sensitive operation has the smallest possible scope, validates inputs, writes an audit, and before execution shows the person exactly what will happen. For actions like an invoice cancellation, idempotence is also important, so that a repeated call doesn’t create a second change.

Equally important is defending against prompt injection. Text downloaded from the web, an email, or a document is untrusted input, not an instruction with the right to change the agent’s behavior. Recommendations for authorization, token management, and handling risky inputs are also summarized in the MCP security best practices.

What I took away from the production deployment

The hardest part wasn’t writing a prompt that produces a nice email. The hardest part was deciding where the truth comes from, how it’s updated, and what exactly each tool is allowed to do.

A working system rests on fairly ordinary things:

content is divided by purpose and authority;
current transactional data is read from an API, not from an old index;
knowledge collections are synchronized continuously;
a single source of truth is used by multiple specialized interfaces;
write actions are narrow, audited, and confirmed by a human;
the client can change without me rewriting the business logic.

Chat is the visible tip of this system. The real value is beneath it: a live knowledge layer, connections to company systems, clear permissions, and tools designed for specific work.

It’s precisely thanks to this that today the same foundation doesn’t only prepare email drafts. It can answer website visitors, help with content, check customer purchases, and via MCP expose selected operations wherever the client needs them right now — on a laptop, in a web chat, or gradually in other interfaces as well.