A Claude-centric software architecture

Abstract

For the past thirty years, software has followed one pattern: the user operates a front-end interface, the front end calls back-end services, and the back end completes the business logic and returns a result. When user needs change, the team has to change both front-end and back-end code to absorb them. Code, fundamentally, is a snapshot of real-world requirements at one moment in time; when requirements change, code must keep changing. As agent runtimes such as Claude Code mature, that structure is being redefined.

This piece proposes a software architecture with Claude at its centre: Claude Code acts as the runtime and the single caller, connecting databases, caches, functions and Skills. Users interact with Claude in natural language and receive results generated on the spot, in whatever medium fits: web pages, text, audio, video.

1. The structural inefficiency of the traditional paradigm

Under the traditional architecture, meeting fast-changing user needs is inefficient. Code is a mapping of requirements at a moment in time; requirements keep changing, the mapping goes stale, and the team keeps going back to rewrite. The substance of software maintenance is people repeatedly re-translating shifting requirements into fixed code. When the requirements are vague, personal, and different for every user, forcing them into rigid code structures (layers of filters and conditional branches) is both expensive and brittle.

Take e-commerce search. A traditional site like Amazon gives users a large set of input boxes, selectors and buttons, and users submit queries through these fixed components. When the existing filters can’t express some personal need, the platform has to route that need to a product manager for research, design a new interface entry point, and schedule engineering and release: weeks at best, months at worst. This fixed “interface to back end” mapping is the root of the inefficiency.

2. Why a Claude-centric architecture is better

The advantage of a Claude-centric architecture is concentrated in one change: how work gets dispatched.

Claude, as the AI agent and the runtime foundation, takes on the unified dispatching role. When a user enters a request, Claude analyses the intent and decomposes it into sub-tasks; it then looks for solutions among the connectors (MCP and others) and Skills it can call, fills gaps with live web search where necessary, and finally generates and returns the result as images, video, audio or text.

Under this paradigm, front-end engineers no longer add an interface or an interaction component for every personal need; the vast majority of presentation is generated on demand by the runtime. Response time to a new requirement shrinks from weeks or months to seconds or minutes.

3. The components

Runtime: Claude Code

The runtime does not need to be built; it is Claude Code. It provides the agentic loop, a file system, code execution, external connectors and the Skill mechanism. The most fundamental change is in the calling relationship: underlying capabilities are no longer called by other code but by Claude, and Claude is driven by the user’s natural language. The starting point of a call moves from code to language.

The Skill layer

A Skill carries business methodology, not code. It consists of a set of instructions (method and process) and the keywords exposed to the runtime; when the user’s natural language hits those keywords, the runtime invokes the Skill and executes according to its method. Its role resembles a “feature module” in traditional architecture; the only difference is that it is triggered by language instead of by a code call.

Structurally, a Skill usually corresponds to one business process in traditional software. Take “deep research on a single stock”: the process typically runs through fundamentals, valuation, technicals and earnings data in turn; the order of execution, the decision logic and the orchestration are all described in natural language in the Skill and invoked by the runtime as needed.

Technically a Skill can bundle scripts. This architecture deliberately keeps Skills as pure methodology and pushes executable logic down into the data and function layers, for a cleaner boundary.

The data layer

This architecture still needs code, but its role has changed: the back end is no longer responsible for interfaces. It evolves into a pure data-and-operations service, providing data and exposing operations, connected to the runtime through MCP or another protocol.

Logically the data layer corresponds to the CRUD layer of traditional software: querying, writing, updating and deleting basic data, plus access to external databases and third-party APIs. Its consumers are the Skill layer and the runtime.

Design principle: expose this layer as a set of small, composable primitives behind stable contracts, not as an end-to-end black box. Let the runtime orchestrate the primitives itself, so every step is visible, trustworthy and auditable. If all you offer is a single “do everything” endpoint, you have handed judgement back to frozen code and returned to the old path.

The function layer

The function layer holds highly atomic pure functions that almost never change with business requirements. The canonical example is the arithmetic of a DCF valuation: logic that is correct as a matter of fact over the long run, not a product of business orchestration.

The difference between the two layers: the data layer answers “where does data come from and where is it stored”; the function layer answers “how to compute deterministically on top of that data”. Together they form the plane of deterministic logic, the stable ground the runtime can call with confidence.

The presentation layer

The interface is no longer the focus of the software, and it is not limited to one form: it can be a chart or web page rendered on the spot, a spoken answer, a video, or plain text. A little front-end code may remain (brand theme, a fixed container), but most presentation is generated on demand by the runtime and discarded after use.

Users can also tell Claude directly how they want the result presented, as audio, image, video or text, and the runtime outputs accordingly. As generation speed and quality keep improving, interfaces become lighter and no longer worth freezing in advance and maintaining for years. What software genuinely needs to design with care is which data and capabilities it provides.

The architecture at a glance

User (natural language)
      │
      ▼
┌───────────────────────────────────────────────┐
│  Runtime · Claude Code                        │
│  agentic loop · file system · code exec · MCP │
│                                               │
│  ┌──────────────┐   invoked by keyword         │
│  │  Skill layer │  business method, prose only │
│  └──────┬───────┘                               │
│         │ orchestrates                          │
│  ┌──────┴───────┐  ┌──────────────┐            │
│  │  Data layer  │  │ Function layer│            │
│  │  CRUD · ext. │  │ deterministic │ ← settled  │
│  │  APIs · MCP  │  │ pure functions│   logic    │
│  └──────────────┘  └──────────────┘            │
└───────────────────────┬───────────────────────┘
                        ▼
        Presentation: generated on demand, then discarded
        web · charts · text · audio · video

4. Where it applies

Online services: e-commerce

Imagine the interaction of the future. The user says, in plain language: “Budget under 8,000, good-looking, lots of memory, pick me a phone.”

The e-commerce provider connects via MCP or a similar protocol, but may offer no front end at all, only data services: product information, inventory, order endpoints and operational APIs. Personal, fuzzy, judgement-laden needs like “good-looking”, “lots of memory” and “right for me” are no longer implemented as fixed filter rules. The runtime parses the intent, calls the relevant endpoints to query, filter and rank, renders the result on the spot, and can place the order.

The commercial implication is worth stressing: the platform only has to be a high-quality provider of data and operations, while “understanding the user”, the most differentiating step, moves up into the runtime. That redraws the division of labour and the distribution of value along the software value chain.

Local tools: quant-researcher

quant-researcher is an open-source US-equity research system built on this architecture. The user talks to Claude Code in natural language (“deep-dive NVDA”, “how’s my portfolio doing”, “find cheap quality compounders”), and underneath it drives a data warehouse, screens, valuation, backtests and a decision ledger, then writes the conclusion. The user never touches a command line.

Its layers map exactly onto the ones above:

Data layer: a command-line tool called qr handles fetching, storage and basic queries, exposing a small set of primitives to the runtime. Every command outputs a single fixed-structure JSON envelope; it never interprets intent and never narrates.
Function layer: DCF, PEG and relative valuation, the deterministic logic, live here. Every run is snapshotted and archived, never regenerated.
Skill layer (methodology): carried by CLAUDE.md and rule files auto-loaded per directory. No code; what it captures is the method for going from natural language to orchestration.
Runtime: Claude Code reads that manual, decomposes a request into a chain of qr calls, executes them, and produces the narrative, the judgement and the conclusion.
Presentation layer: by default an on-the-spot written conclusion; deep reports worth keeping are generated as HTML files and archived.

Notably, the system also answers the usual worry about reproducibility: the data and function layers are both point-in-time correct. Financial data is stamped with the date it became available, ruling out look-ahead bias; every result carries an as_of stamp and a code version, and every decision snapshots the data it was based on, so it can be reviewed and evaluated later. The lesson: making the deterministic part solid is precisely what lets you hand the uncertain part to an agent with confidence.

5. Business value

Capability as asset, and as moat. What accumulates over time is the capability and data in the data and function layers, not perishable interfaces. The competitive barrier shifts from “how many screens we built” to “how much capability we have settled”.
Lower maintenance cost. The presentation layer stops being a code asset that needs continuous upkeep. Front-end release cycles, A/B tests and restyling shrink dramatically, and engineering effort concentrates on the stable capability layers.
Auditable and reproducible. Deterministic logic (data plus function layers) is designed to be point-in-time correct and snapshottable, so the agent’s judgements can be traced and evaluated, which suits compliance and risk requirements.
A reshaped value chain. Providers focus on being data-and-operations suppliers, the differentiating “understand the user” step is taken by the runtime, and platforms and application builders gain new room in division of labour and pricing.

6. Boundaries and trade-offs

Every architecture has costs, and they should be stated plainly:

Latency and cost. Every interaction runs an agent loop, parses the request and generates presentation; that is slower and more expensive than a frozen application. Latency-critical, high-frequency operations should not be handled in real time this way.
Reproducibility. Presentation generated live by the runtime is inherently non-deterministic. Scenarios that need audit, compliance or strict consistency must rest on the deterministic logic in the data and function layers.
Permissions and safety. The runtime can execute code, access files and connect to accounts and payments. Permission control and sandboxing are prerequisites, especially where real money and real orders are involved.
Deterministic guardrails on critical paths. Free interpretation suits “retrieve and judge”. The final step of any irreversible action (placing a real order, transferring funds) should go through a deterministic service endpoint in the data layer, not code the runtime generates on the fly.
Who it suits. Best for individuals or small teams building tool-like software for themselves or for expert users, where requirements are highly varied and impossible to enumerate in advance, and for platforms willing to focus on data and operations. For mass-market products serving huge numbers of ordinary users with a highly consistent experience, the traditional paradigm remains the safer choice.

Closing

For decades the software industry has used human labour to translate changing requirements into code, again and again. Once a runtime like Claude Code is strong enough, the more efficient approach is to separate the two kinds of requirement: settle deterministic logic into the data layer, the function layer and Skill methodology; hand uncertain requirements to the runtime to understand, map and render in real time.

What a team then has to maintain over the long run is no longer interfaces but unchanging capability and data. That is an engineering choice and a business choice at once.

中文版.