Introducing Quater: a Python backend framework for humans and AI agents

Most backend frameworks were built around a very familiar shape of software - A human opens a frontend. The frontend shows buttons, forms, tables, filters, and dashboards. The human clicks around, submits something, and the backend quietly does the real work behind the scenes.

That model is not going away. People still need good interfaces. A well-designed product UI is still the best way for a human to understand what is happening inside a system and make decisions with context.

But I do not think that model is enough anymore.

Software is getting another kind of operator: AI agents.

Not a user in the normal product sense. An agent does not need a beautiful dashboard to understand an order. It does not care about a sidebar, a modal, or the exact placement of a button. Most of the time, it needs the operation behind the interface: fetch this order, create this record, update this status, run this report, trigger this workflow, summarize this data.

Asking an AI agent to operate software by clicking through screens feels like the wrong abstraction. It can work for demos, but as a serious interface for backend operations it is fragile. A label changes, a button moves, a modal appears, a page layout shifts, and suddenly the automation is guessing again.

That is the problem I started thinking about while building Quater.

The problem is not only agent access

When people talk about AI agents using applications, the conversation often jumps to browser control, API wrappers, or MCP servers. All of those can be useful, but I think the deeper problem is where the actual operation lives.

In many projects, the same piece of business logic slowly spreads across different places.

The web app has an endpoint. Then someone writes an internal script for the same action. Later a support tool needs it, so a small admin function appears. Then an agent needs to perform the action, so another tool function gets created. After that, a CLI is added because operators want to run it from the terminal.

Nothing looks too bad on day one. But over time, each version starts to drift. One path has better validation. One path checks permissions correctly. One path returns a different response shape. One path gets updated when the product changes, and another quietly keeps the old behavior alive.

This is how teams end up maintaining separate applications without calling them separate applications.

There is the real backend. Then there is the agent backend. Then there are admin scripts, CLI tools, MCP wrappers, cron helpers, and glue code around all of them. They may live in the same repository, but operationally they behave like different systems. They need to be documented, deployed, secured, tested, and kept in sync.

AI agents make this problem more visible because they introduce a new caller into production systems. The question is no longer only, “Can this operation be called?” The better question is, “Who or what called it, through which entry point, with what permissions, and should it have been allowed?”

In a lot of backends, the answer is hard to reconstruct. A request reaches the application, some logic runs, and later the logs only tell you that something happened. They do not clearly tell you whether the action came from a human using the product, an MCP client, a local CLI call, a remote CLI call, or an AI agent operating on someone’s behalf.

That is not enough if agents are going to touch real workflows.

What Quater is

Quater is an open-source Python backend framework built around a simple idea: the backend operation should stay the source of truth, but it should be reachable through the surfaces that make sense.

You should be able to build a normal web backend for humans and services. Then, when a specific operation should also be available to agents or operators, you should be able to expose that operation directly instead of rewriting it somewhere else.

In Quater, a route can serve HTTP, become an MCP tool, and become a CLI action.

The key part is that these are not three separate implementations. The same handler owns the logic. The same route remains the place where the operation is defined. The extra surfaces are opt-in.

Here is a small example.

from quater import Quater

app = Quater()

ORDERS = {
    "ord_1001": {
        "id": "ord_1001",
        "customer": "Aarav Mehta",
        "status": "paid",
        "total": 2499,
    },
    "ord_1002": {
        "id": "ord_1002",
        "customer": "Maya Kapoor",
        "status": "pending",
        "total": 1299,
    },
}


@app.get(
    "/orders/{order_id}",
    tool=True,
    cli=True,
    description="Fetch one order by id.",
)
async def get_order(order_id: str):
    order = ORDERS.get(order_id)

    if not order:
        return {"error": "Order not found"}

    return order

This is still a normal HTTP route. A frontend can call GET /orders/ord_1001 like it would in any backend application.

But because the route is marked with tool=True, Quater can expose it as an MCP tool. And because it is marked with cli=True, Quater can expose it as a CLI action too.

The important thing is what does not happen. You do not create a separate agent service. You do not copy the function into a script. You do not maintain another schema file far away from the actual route. You do not build a second backend just because a new kind of caller arrived.

The operation stays inside the application that already owns it.

How MCP works from the user’s side

MCP is useful because it gives AI clients a structured way to discover and call tools. Instead of an agent guessing its way through a screen, it can ask the application what tools are available and call one with structured arguments. MCP tools are described with names, metadata, and input schemas, which makes them much easier for AI clients to reason about than a visual interface.

From the application developer’s side, Quater keeps that flow close to the route. If a route is safe and useful for an AI client, you opt it in with tool=True and give it a description. Quater generates the tool schema from the route parameters and exposes it through the MCP endpoint.

From the user’s side, the experience is much simpler. They connect their MCP-capable client to the Quater app, for example to /mcp, with the right authentication. The client can then discover tools such as get_order, understand the inputs it needs, and call it when the user asks something like “check order ord_1001”.

The agent does not need to know the frontend. It does not need to scrape the UI. It does not need a custom wrapper written separately from the backend. It sees a described tool, passes the required arguments, and the Quater app decides whether that request is allowed.

That last part matters. MCP access should not mean “everything is open now”. Quater keeps MCP auth separate from route auth, so the application can protect the MCP surface and still protect the underlying operation. For sensitive actions, approval can also be required before the operation runs.

This is the difference between giving agents access and giving agents unlimited access.

Why CLI matters just as much

MCP is not the only way agents are going to operate software.

A lot of agent work is already happening around terminals. Developer agents, coding agents, infrastructure agents, and tools like OpenClaw-style workflows often live very close to the command line. They run commands, inspect output, search available actions, and decide the next step from there.

That makes the CLI an important interface, not an afterthought.

For humans, the CLI is useful because production work often starts in a terminal. During an incident, a support case, a rollout, or a debugging session, someone may need to inspect state or trigger a backend operation directly.

For agents, the CLI is useful because it gives them a text-native interface that is easy to discover, easy to call, and easy to reason about. A CLI action can be listed, searched, described, dry-run, and then executed with explicit arguments.

Quater’s CLI is built around that workflow.

You can connect a deployed app once:

quater connect store https://api.example.com --token admin-token

Then discover what the app allows:

quater actions list store

For a small application, listing actions may be enough. But real applications can have hundreds of operations, so discovery needs to scale. That is why actions can be searched before they are called:

quater actions search store order

Once the caller finds a relevant action, it can inspect the exact schema and usage:

quater actions describe store get_order

Only after that does it call the operation:

quater call store get_order --order-id ord_1001

This flow is useful for both people and agents. A human operator can use it directly. A terminal-native agent can follow the same steps without needing a browser. In a large application, the agent does not have to load every possible action into context at once. It can search, describe, and call only what it needs.

That is a more practical way to make an application operable from the command line.

Operating skills for applications

One idea I am especially interested in is that companies should be able to ship operating skills for their own applications.

A product already has documentation for humans: how to use the dashboard, what each page means, how support workflows should be handled, what needs approval, and what should never be touched casually.

Agents need a version of that too.

With Quater, an application can expose a controlled set of operations through MCP and CLI. On top of that, a company can provide instructions for agents explaining how to use those operations safely: how to connect to the remote, how to search actions, which actions are read-only, which ones need approval, which ones should be dry-run first, and what errors mean.

That turns the application into something an agent can learn to operate without the company building a separate agent-only backend.

This is a very different model from “let the agent click around and hope it understands the product”. It is closer to giving the agent a proper operating manual and a safe control surface.

Knowing how the backend was called

When humans are the only users of a system, it is easy to think of backend traffic as just requests.

But once HTTP clients, MCP clients, local CLI calls, remote CLI calls, internal workflows, and AI agents all touch the same application, the entry point becomes part of the story.

If an order status changed, it matters whether the change came from the dashboard, from a support tool, from an MCP client, or from a remote CLI action. If a report was generated, it matters whether a human asked for it or an agent triggered it during a workflow. If a sensitive action failed, it matters whether auth failed at the MCP surface, at the CLI surface, or at the route itself.

Quater carries source and entrypoint metadata through the request flow so the application has that context available. Audit logs can then answer better questions than “which endpoint was hit?”

They can answer how the operation entered the system.

That is going to matter more as agents move from demos into real company workflows.

Safety should not be bolted on later

Agent access sounds exciting, but the boring parts decide whether it can be trusted.

Host checking, CORS, body limits, request IDs, auth boundaries, approval gates, audit hooks, and safe defaults are not the shiny parts of a framework. But they are the parts you miss very quickly when something goes wrong.

Quater tries to keep those concerns close to the framework. Security defaults are enabled by default. The request carries useful metadata. MCP and CLI auth are explicit. Route auth still belongs to the operation. Sensitive actions can require approval instead of relying on auth alone.

No framework can make an application safe automatically. Developers still need to design permissions correctly and decide what should or should not be exposed. But the framework should make the safer path feel natural.

That is the goal.

Not every route should become an agent tool

This is worth saying clearly.

Quater is not about exposing your entire backend to agents.

Some routes should stay HTTP-only. Some operations make sense as MCP tools. Some internal workflows make sense as CLI actions. Some actions should require approval. Some should never be exposed outside the normal application flow.

The model is intentionally explicit. A route becomes available to MCP or CLI only when the developer chooses that surface.

That is important because agent access should be a design decision, not an accident.

Performance still matters

Quater is being built for the agent era, but it still has to behave like a real backend framework.

I have been benchmarking it against FastAPI while building it. For tiny endpoints that do almost nothing, FastAPI can be faster because those benchmarks mostly measure framework overhead. That is expected.

Once the benchmark includes real database work, Quater performs slightly better in my latest runs, with no meaningful overhead when database I/O dominates the request.

That distinction matters because real backends usually do more than return hello world. They validate input, check permissions, read from databases, call services, and write state. Quater is being built with that kind of workload in mind.

What I am announcing

Quater is still early, but it is now ready for people to look at properly.

I recently released the second alpha, and this is my first real public announcement of the project.

It is open source, Python-based, and built around a direction I strongly believe in: backend frameworks should not only serve frontends anymore. They should also provide safe, intentional, structured ways for agents and internal workflows to operate the application.

That means a backend should be able to serve a human through HTTP, an AI client through MCP, and an operator or CLI-native agent through actions, without turning the same operation into separate code paths.

More importantly, it should do that with auth, validation, metadata, approvals, and ownership still attached to the application logic.

That is what I am trying to build with Quater.

Where this is going

I think the next generation of backend frameworks will need to think beyond request and response over HTTP.

They will still need to serve web apps. They will still need to be fast, simple, and reliable. But they will also need to support a world where software is operated by humans, services, scripts, MCP clients, and AI agents together.

The backend should not become a hidden box behind a frontend. It should become a safe operating layer for the application.

Quater is my attempt at building toward that future.

If this direction sounds interesting, I would love for people to try it, break it, question it, or follow along as it evolves.