One application, three doors: systems ready for people, automation and AI assistants

For many years, an information system was used mostly by people sitting in front of a screen. Today, requests also come from other systems, from automated tasks that run in the early hours and, more and more, from artificial intelligence assistants working on someone's behalf. Each of these users arrives through a different door, and all of them expect the system to apply the same rules.

To help build systems that are ready for this, Datapoint has released Datapoint.Mediator, an open-source library, free to use, that lets you write a system's rules once and offer them through three different doors. Version 4.0 is available in beta, and anyone can read, use and improve the code in the repository at github.com/datapoint-software/mediator.

One bank, three counters

Think of your bank. You can be served at a branch counter, take out cash at a cash machine or make a transfer in the app on your phone. These are three very different ways of getting to the same place, but the rules on your account are always the same: the balance is the same, the limits are the same and only those who are authorised can move the money.

Nobody would accept a cash machine that forgot to check the daily limit because that check had only been programmed at the counter. And yet this is exactly what can happen in an information system when each way in is built separately.

The three doors of a modern application

A next-generation application should be ready to take requests through three doors:

• The API. An API, or application programming interface, is how other systems, websites and mobile apps talk to the system, machine to machine. It is the door we already know, and it is still essential.

• The command line. A command line, or CLI, lets you give the system instructions by typing commands in a terminal. It is used by technical teams and by automated tasks, such as month-end closing or the nightly data import, and more and more by AI assistants that work directly in a terminal.

• MCP. MCP, the Model Context Protocol, is an open standard that lets an AI assistant find out which operations a system offers, understand what each one is for and request them on a person's behalf.

The API has been around for a long time. The command line and MCP are what set apart the applications that are ready for the way we will work in the coming years, when some repetitive tasks will be requested by automated processes and assistants, always under someone's responsibility.

The risk of doing everything three times

The obvious way to offer the three doors is to build each one separately. The trouble is that every door needs to know the same things: who may do what, which data is valid and how to save information consistently. When those rules are written three times, sooner or later they stop being the same. A change made in the API is forgotten in the command line, or a permission check never reaches the AI assistant.

If a rule is only checked at one of the doors, the other two become a way around it.

Besides the security risk, there is the cost: every new operation has to be built, tested and maintained three times, and every new door you want to open in the future means repeating all that work.

One request, three ways in

Datapoint.Mediator solves this by separating two things: what the system does, which is written once, and the doors that lead to it, which are simply different ways of making the same request. Take the request "issue an invoice to Ana for 100 euros":

Door	Who uses it	How the request arrives
API	The invoicing program, the website or the mobile app	POST /api/invoices/create
Command line	The technical team or the month-end automated task	invoicing invoices create --customer Ana --amount 100
MCP	An AI assistant someone asked to issue the invoice	The tool invoices_create

Through any of the three doors, the request follows exactly the same path inside the system and goes through the same checks:

1. Is the requester allowed? By default, the answer is no: an operation can only be used by those who have been explicitly authorised. An AI assistant can never do more than the person it works for, and it can be set up to do less.

2. Is the data right? A missing or mistyped value is refused before anything changes, with the same message at every door.

3. Is everything saved, or nothing? If an operation has several steps, either all of them are saved or none is. There are no half-issued invoices.

4. Is it on record? Every request leaves the same trail, wherever it comes from, which makes it easier to see what happened and how long it took.

What your organisation gains

• More security. Access rules are written in one place and apply to every door. Error messages do not repeat the data sent or reveal internal details, and operations that change data are flagged as such to AI assistants, so they can ask the person for confirmation before going ahead.

• Lower cost. Each rule is written, tested and maintained once. Opening a new door does not mean rebuilding the system.

• Ready for AI, without starting over. A system built this way can open its door to AI assistants whenever the organisation decides to, with the same permissions it already applies to people, and with a choice of which operations are available.

• A common trail. Every request is measured and recorded in the same way, which makes auditing and spotting problems easier.

• No lock-in. The library is open source, under the MIT licence, and MCP is an open standard. Any team can use, study and adapt the code.

Three questions to ask your software supplier

Even if you are not technical, you can use these questions to find out whether your organisation's systems are ready to take requests from automated processes and AI assistants:

1. If an AI assistant uses our system, is it bound by the same permissions as the person it works for?

2. Are the system's rules written once, or repeated for each way in?

3. Can we add a new way in, such as a command line or an MCP server, without rebuilding the system?

For development teams

This section is more technical. Datapoint.Mediator is a set of NuGet packages for .NET 10 that implements the Mediator pattern: components send commands and queries through a mediator instead of calling their handlers directly. In version 4.0, every command or query can be given a name with the [Action] attribute, and each door becomes one line of configuration:

// Business layer: the operation is defined once
[Action("invoices.create", Description = "Creates an invoice for a customer.")]
public sealed record CreateInvoice(string Customer, decimal Amount) : ICommand<Guid>;

// Each door is one line
app.MapActions("/api");                          // API: POST /api/invoices/create
root.AddActions(services);                       // CLI: invoicing invoices create --customer Ana --amount 100
services.AddMcpServer().WithMediatorActions();   // MCP: the tool invoices_create

• Shared behaviours. Authorisation (which denies by default), validation with FluentValidation and transactions with Entity Framework Core run in that order at every door, as do the behaviours you write.

• The right user at each door. The API uses the HTTP request's user; the command line and a local MCP server use a fixed user, set at start-up.

• Secure by default. An action with no authorisation rule is refused; hidden actions fail in the same way as actions that do not exist, so they cannot be discovered; errors never repeat the input received; and invalid configurations fail at start-up.

• Documentation and observability. The API publishes OpenAPI metadata, the command line generates help for every command, MCP tools use the actions' descriptions, and every request is measured with OpenTelemetry.

To get started, install the packages with dotnet add package Datapoint.Mediator.DependencyInjection --prerelease and explore the invoicing sample in the repository, which offers the same business layer as an API, a command line and an MCP server. The manual, the samples and the code are at github.com/datapoint-software/mediator. As this is a beta release, we welcome suggestions and bug reports in the repository itself.

How we work

At Datapoint, we develop, integrate and maintain information systems, and we believe a good system should be ready for the people who will use it tomorrow, not just those who use it today. We have published Datapoint.Mediator as open source so that any team can use, study and improve it. If you want to get your organisation's systems ready to take requests from automated processes and AI assistants, see our MCP integration or get in touch.

Further reading

• Datapoint.Mediator, code, manual and samples on GitHub

• Datapoint.Mediator, packages on NuGet

• Model Context Protocol, the open standard for AI assistants