| 11 min read

From App to Agent: Why Classic Applications Won't Disappear, but Will Look Different

AI Agents MCP Architecture UI

Also available in German: Von der App zum Agenten: Warum klassische Anwendungen nicht verschwinden, aber anders aussehen

The thesis

Classic applications are not going away. They are, however, losing their role as the place where people type in data, and becoming the reliable core that agents and people work on together.

“The future is AI agents and chat” is something I now hear in almost every project conversation. The obvious follow-up question: should we still build forms, input screens and dashboards at all? My answer after several months of running my own agents day to day: yes, but differently. The real question is less “app or agent” and more: who does the work, and where does the human decide?

In this post I describe how the architecture shifts as a result, and show it with two examples of my own: my receipts agent for bookkeeping, and HourPay, which started as a classic time-tracking app and now runs as an agent.

What stays: the deterministic core

Agents need something to act on. That is exactly what classic applications have always done well: a clean data model, business rules, permissions, transactions and an audit trail.

A language model is probabilistic. A booking, an invoice or a statement of work has to be deterministically correct. That is why the core does not become less important but more important: it is no longer called by a single UI, but by any number of agents that access it faster and more often than any human.

In its guide to effective agents, Anthropic deliberately distinguishes between workflows with a predefined flow and agents that steer their own path, and recommends starting with the simplest solution (Building effective agents). My reading for enterprise software: intelligence belongs at the edges, truth belongs in the core.

API and MCP first, the interface second

If you build an application today, design the domain logic first as a clean API and additionally expose it as an MCP server. The UI then becomes just one client among several.

The Model Context Protocol has become the de facto standard for how agents access tools and data. In December 2025, Anthropic handed MCP over to the newly founded Agentic AI Foundation under the Linux Foundation, backed among others by OpenAI, Google, Microsoft and AWS (Phoronix). That makes it no longer a vendor format but open infrastructure, comparable to the Language Server Protocol for IDEs (MCP specification).

In practice, this means designing tools the way an agent needs them:

  • Named by domain: record_work_entry, not POST /api/v2/entries.
  • Idempotent and validated: Agents retry calls. Duplicate bookings must be caught by the core, not the model.
  • With clear permissions: reading, proposing and booking are separate rights.
  • With events, not just CRUD: agents should be able to react to events, not only query.

Build it this way and you have an application that a person can use through a UI, an agent through MCP and another system through the API, all equally. In my own setup this is not a vision of the future: my agents reach mailboxes, documents and other systems through MCP servers instead of hand-built integrations.

UI on demand: the interface appears where it is needed

Chat is a good entry point but a poor results view. You happily type “show me all open items older than 30 days” in natural language. But you want the result as a table you can sort and tick off, not as prose to read.

The answer is UI on demand: the request arrives as intent, the response as a fitting view. There is now a standard for this. With MCP Apps (SEP-1865), MCP servers can deliver interactive interfaces directly to the chat client, where they run in a sandboxed environment (SEP-1865). The extension unifies the approaches of MCP-UI and OpenAI’s Apps SDK. It is supported in ChatGPT, VS Code Copilot Chat and Goose, among others (morphllm).

For application developers, this shifts the question. No longer “which input screens does the app need?” but “which views does a person need to make a decision?” There are usually three kinds:

  1. Overview: dashboards and lists you take in at a glance.
  2. Review: the agent’s proposals with reasons, ready to approve or correct.
  3. Exceptions: whatever the agent could not assign with confidence and needs a human answer.

Everything else, meaning the classic input form, becomes the exception for cases that leave no digital trace.

Data capture, rethought

Data capture changes the most. People no longer retype what already exists as a trace; they confirm a draft.

Almost every working hour and every expense leaves traces: calendar entries, commits, tickets, emails, invoices, bank transactions. An agent reads these sources, builds a proposal with its reasoning, and the core checks it against fixed rules such as required fields, valid projects, daily limits or locked periods. Only then does a human see it.

The agent drafts, the human decides, the system books Signals Mail, calendar, Git, bank data Draft Agent proposes, with reasons Rules Core checks fixed rules Approval Human reviews and confirms Booking System of record with audit trail Corrections go back to the agent

Whatever leaves no trace, such as a phone call or an on-site meeting, is added freely: as a chat message or voice note that the agent turns into a structured entry. The same pattern works for receipts, travel expenses, maintenance logs or CRM upkeep.

Example 1: the receipts agent

My monthly bookkeeping now runs through an agent that collects receipts and matches them. Nothing is booked until I confirm.

The starting point was classic: an expense ledger as a macro-enabled Excel file in SharePoint that I filled in by hand every month. Receipts came from Gmail, Outlook, Amazon and on paper, plus bank and credit card statements to reconcile against.

The agent did not replace the spreadsheet. It replaced the typing:

  • Signals: invoices from the mailboxes, orders, bank statements, photographed paper receipts. The agent reaches the mailboxes through MCP servers.
  • Draft: a local model behind a LiteLLM gateway in my homelab proposes matches between receipts and transactions and writes them to a suggestions file.
  • Rules: the normal flow stays deterministic, as scripts. The model may propose but never book.
  • Approval: I review the proposals. Only then is an import file created, which a button transfers into the expense ledger.
  • System of record: the ledger itself is never changed directly, backups included.

The result is unspectacular in the best sense. The Excel file that goes to my tax advisor looks the same as always. The only thing that changed is who does the work.

Example 2: HourPay, from timer app to agent

HourPay started as a classic app and now runs as an agent. This project shows the shift most clearly.

The first version in spring 2026 was textbook web development: React and TypeScript on the front end, Node.js with SQLite on the back end, a live timer, clients and categories, a monthly dashboard, CSV and Excel export, and finally a statement of work as a PDF with signature lines. The data source was me: start the timer, stop it, pick a category, type a description.

That part was exactly the problem. Time tracking rarely fails because of the software. It fails because you forget to press the timer.

The agent version turns this around. It pulls together what I worked on from the traces of my working day and builds the entries from them. The input form becomes a review.

HourPay as an appHourPay as an agent
Who capturesme, via timer and formthe agent, from existing traces
Role of the humanenter datareview and approve the draft
Main interfacetimer and input formreview before month-end close
Data model and rulesclients, categories, roundingunchanged
Outputstatement of work as PDFunchanged

The last two rows are the real point. What the client sees and signs at the end has stayed the same. All that disappeared is the screen where I typed in data.

A topic of its own: model routing

When every work step can be a model call, choosing the model becomes an architecture decision. Which task does code solve, which a small local model, which a large frontier model, and who decides that at runtime? For the receipts agent, the answer today is deliberately simple: script first, the model only where the script finds no unambiguous match, and financial data stays inside my network.

Behind this sits a topic of its own, with gateways, cost, data protection and fallbacks. It will get a dedicated post.

Where the limits are

Not every application becomes an agent, and not every agent is a good idea. I see four limits in practice.

Classic UI stays where speed and routine matter. Point of sale, IDEs, CAD or dispatch live on high frequency and muscle memory. Putting a chat in front of them makes them slower, not better.

Many agent projects fail. Gartner expects more than 40 percent of agentic AI projects to be cancelled by the end of 2027 due to cost, unclear value or inadequate risk controls. Even so, Gartner expects around a third of enterprise software to include agentic AI by 2028 (Gartner). Both fit together: agents pay off where they take real work off people’s hands, not as a label.

Data protection and labour law. As a sole proprietor, it is no problem for me if an agent analyses my calendar and commits. Inside a company, this quickly becomes a monitoring measure. In Austria, systems that monitor employees and affect human dignity require the works council’s consent in the form of a works agreement (§ 96 ArbVG). Without a works council, employees must consent individually (§ 10 AVRAG). The Austrian Supreme Court’s decision on biometric fingerprint scanners shows that time tracking can fall under this (OGH).

Traceability. Billable hours and booked receipts must remain verifiable. That is why nothing is submitted automatically in my setup: every entry carries its reasoning, which signals support it, and a human approves.

Outlook and rules of thumb

The coming years do not belong to chat instead of apps, but to applications that cleanly separate who does the work and where the human decides.

Gartner describes this development in stages: from embedded assistants, through task-specific agents in individual applications, to agent ecosystems that collaborate across applications (Gartner). I see the direction confirmed in my own daily work.

My next step is topic agents: one agent per area that knows everything about its topic, for example for the homelab or the receipts. Each of them talks to its systems through APIs and MCP, and the same pattern applies everywhere.

If you start a new project today, six rules help:

  1. Build the core solidly: data model, rules, permissions and audit, classic and deterministic.
  2. API and MCP as the primary interface: domain-named, idempotent tools with separate rights for reading, proposing and booking.
  3. Replace capturing with finding: use existing traces instead of making people type.
  4. UI on demand: lean interfaces for overview, review and exceptions, with chat as the entry point.
  5. Route models through a gateway: code before a small model before a large model, roles instead of hard-wired model names.
  6. No auto-submit: the agent proposes, the human approves, the system books.

Sources

Transparency: This post was created with AI assistance. I reviewed it and take responsibility for the content. More under AI Transparency.