Building a microapp inside a plugin: Architecture and tradeoffs

A skill inside an AI plugin is normally a procedure the agent runs on your behalf. It fetches some data, does something with it, and returns a result in the conversation. Microapps work differently. The output is a running application, and the conversation is the mechanism for launching it. Each architectural decision behind that comes with a cost.

The core constraint: MCPs are not API calls

A traditional web app fetches on demand. The user interacts with the interface, it hits an endpoint, and the page updates. MCP tool calls carry more latency than a direct API call, and that gap is not something you can close at the design level.

The practical response is to change when the fetching happens. Rather than fetching whenever the interface needs data, you fetch once at launch, write the result to a local snapshot, and run the app against that copy for the rest of the session. If the underlying data has changed, the user re-runs the pull.

This sounds like a limitation, and for some use cases it would be. For Fund Modeling, portfolio marks change quarterly. A snapshot taken at the start of a session is current for months. The rule this produces is a useful filter: Microapps fit use cases where the data refresh cadence is measured in weeks, not seconds.

What ships in the plugin package

Four layers go in together.

• The skill markdown holds the instructions the agent follows: which firm to resolve, what to fetch, in what order, how to handle edge cases, and how to start the server at the end. There is no math in it, no business logic, and no app rules. It orchestrates, and that is all. Keeping it that way means you can read and review the skill as plain instructions rather than as code dressed up as prose.

• The query and transform layer is SQL against pre-built data warehouse views, plus the scripts that convert those results into the JSON shapes the app expects. This part is fully deterministic. No AI model is involved at any point in the data path. The numbers take their shape here, and they take the same shape every time.

• The app itself is where all the business logic lives, packaged as pre-built JSX. For Fund Modeling, that means the XIRR calculations, waterfall distribution, repricing logic, and liquidation preferences, with the UI tabs sitting on top of them. This is the layer that would normally have been a server deployment. Shipping it inside the plugin package instead is the decision the entire architecture depends on.

• The fourth layer is a pre-built React shell: local server, service worker, and a vendored copy of React. Its job is to let the app run with no build toolchain, which is what makes the business logic layer above it editable by the customer without setting up a development environment first.

One component stays outside the package deliberately: the user's data directory. The snapshot the app pulled at launch, and any scenarios the user has saved, live there. A package update can replace every line of app code without touching that directory. Separating them is the mechanism by which updates can ship without destroying user work.

Why the browser rather than an artifact

Artifacts handle single-page output well. A fund modeling interface is not a single page, and it was not going to become one. The analysis spans exit scenarios, reserves planning, fund-level and firm-level views, and benchmark comparisons. Each of those carries enough output surface to warrant its own tab.

Three requirements pushed toward the browser. The first is responsiveness: Moving a slider and seeing the impact on carry needs to feel immediate, because the user is not asking one question but exploring a surface, and any latency in that loop shortens the exploration. The second is depth: The interface needs multiple views with the ability to drill into each one. The third is visual fidelity: A partner building a scenario is assembling an argument, and charts carry that argument with less cognitive load than the same data presented in a table.

The browser already has tabs, history, local storage, and print. The runtime fits the problem shape.

Auditability over AI computation

Token usage in a microapp is low because the application is pre-built. The agent spends tokens on the data pull and on starting the server. Nothing after that runs through a model.

The more significant property is that the AI model is not in the compute path for any of the calculations. The same snapshot plus the same scenario always produces the same output. Every calculation is a function you can open, read, and verify.

When an AI model computes something like XIRR inside a conversation, it produces a number you have to take on trust. When a function computes it, you can check the function. For anything touching fund performance or LP returns, that distinction matters enough that we structured the whole architecture around it.

Multiplayer is the hard problem

The feature users ask for most is scenario sharing. Proper sharing requires network round-trips on every read and write. That is the fetch pattern we designed this architecture to avoid, and there is no way to add real-time sync without giving up local ownership.

What we are building instead is versioned scenario storage: A firm publishes a scenario to a central store, and a teammate pulls it on demand. It behaves like sharing a version of a document rather than collaborating on a live one. The trade is intentional.

Keeping the user in context

Telling users they can edit the app is only useful if the friction to do it is low. Editing a file means leaving the app and opening a development environment or a separate AI coding session, which is enough of a context switch that many users may not bother.

Our solution was to embed an AI coding session directly in the app's browser interface. The user can click on a number and ask where it came from, or describe a change they want, without switching applications. The coding session has access to the app's local files and can make changes that are visible on the next refresh.

When to use this pattern

Microapps require MCPs for data connectivity. Without MCP connectors pointed at the right data sources, there is no fetch layer and no snapshot, and the pattern falls apart. Assuming MCPs are in place, the relevant conditions are: data that refreshes slowly, users who need to customize logic or connect proprietary data sources, and workflows that require depth and visual output. If real-time data or live collaboration are hard requirements, a hosted app is the right call. If local ownership and adjustable logic are what the use case needs, this architecture has structural advantages that are difficult to replicate through configuration in a traditional product.

Automation, precision, and insight, everywhere you work

Carta Plugins for Claude bring automation, expertise, and precision to private capital operations.

Explore Carta Plugins for Claude