Use the Language Model for reasoning. Give it a persistent model of what it is reasoning about.
Proxa is a persistent workspace for your team and Claude that works with the files and tools you already use.
Seven sections, eight examples, and the questions we get asked.
00
A Proxa Model is like an Excel model with hundreds of interconnected tabs.
Proxa is a persistent workspace for your team and Claude that works with the files and tools you already use rather than replacing them with another application. In the background, it identifies and organizes the data needed for a shared Domain Model, stays synchronized with its sources, and flags inconsistencies as information changes. With everything in one place, agents can automate the mechanical work of updating spreadsheets, slides, reports, and dashboards, while the team focuses on knowledge work.
The idea is deliberately simple. The files and systems already in use remain in place. Proxa adds a model across them: a structured representation of the information, relationships, logic, assumptions, and processes that matter to the domain.
That Model gives the team and Claude something persistent to work against. Instead of reconstructing the subject from a collection of files every time a question is asked or a process runs, the important structure has already been established and can be refined as the domain evolves.
The result is an environment for modeling rather than another application for a specific workflow. Start with the model needed for one problem, process, or output. Add to it as more questions need to be answered, more processes automated, or more of the domain understood.
01
Built for AI
AI models are extraordinarily good at reasoning, creating, and solving problems. What it lacks in a one-off conversation is a persistent representation of the subject they're reasoning about. Each new task can require the relevant documents, facts, relationships, and prior decisions to be assembled again.
Proxa does not replace the language model or put another abstraction in front of it. The model remains the reasoning engine. The Domain Model gives the AI an explicit representation of the domain, while the workspace provides the persistent state and tools needed to work with it over time.
This changes the interaction. A conversation is no longer limited to answering a question from whatever context happens to be available at that moment. The AI can help build the Model, identify missing information, refine assumptions, perform analysis, update it as new information arrives, and return to the same representation later.
As the underlying models improve, the reasoning layer improves with them. The Domain Model provides the other half of the system: the structured, persistent subject the AI reasons about.
02
Domain Models
A persistent, computational representation of the subject.
A Domain Model can represent a department, project, investment, asset, research problem, operating plan, or any other structured body of information. It makes the important facts, relationships, calculations, assumptions, rules, decisions, and process state explicit and reusable.
A model is intentionally incomplete. It does not attempt to reproduce everything known about a domain. It represents the parts needed to understand it, analyze it, predict how it may behave, and produce the required outputs. The appropriate model for a simple question may be small; a complex domain may develop into a system of connected sub-models.
The relationships are as important as the data itself. A number can be connected to the calculation that produced it, the assumptions behind the calculation, its source, the person responsible for it, and the outputs that depend on it. A decision can be connected to the evidence and reasoning that supported it. A process can be represented as a sequence of states, requirements, and dependencies.
Because these relationships and dependencies are explicit, the Model is computational rather than simply descriptive. Claude can use it to calculate, analyze, test assumptions, trace dependencies, and run scenarios — not merely retrieve and summarize information from documents.
03
Data Layer
The Model’s data layer encodes information from the slides, docs, spreadsheets, and reports you already use.
Most AI systems start by asking for access to as much data as possible. A Domain Model does the opposite. It does not need all of your operational data, just Essential Data — the 1% used for analysis, planning, and reporting. The signal that drives the Model’s analysis, assumptions, and outputs.
The objective is not to copy every source system into another repository. The source systems, spreadsheets, documents, presentations, and other tools remain where they are. Proxa identifies the information the Model actually depends on and encodes it into a structured form that Claude and the team can work with directly.
Essential Data also carries context that is often lost when a value is copied into a spreadsheet or presentation: where it came from, what it means, how it was calculated, who is responsible for it, and what depends on it. That allows the Model to distinguish between two numbers that look similar but mean different things — or recognize when two sources that should agree do not.
The data layer therefore acts as the signal layer for the Model. A relatively small amount of well-defined information can support a much larger set of calculations, analyses, processes, and outputs.
04
The Workspace
Claude Code is a harness for software development. Proxa is a workspace for domain modeling.
Proxa works like a harness. It is what turns a capable language model into a working system. Instead of one-off chats with Claude, the agent works inside a persistent workspace for the entire team, where it can build, update, and maintain the Model over time. The harness provides the context, tools, permissions, state, and history needed to understand the domain and work with its data, logic, methods, and outputs — all guided, reviewed, and validated by the team.
Claude Code provides a useful analogy. Claude already knows how to write software; the harness gives it a codebase, files, tools, permissions, history, and an environment in which it can act. Proxa applies the same principle to domain modeling. The material is different, but the requirement for a persistent environment is the same.
The workspace is also where the team collaborates with Claude. A person can describe what they are trying to model, provide source material, correct an assumption, approve a proposed change, or ask Claude to explore a question. Claude can translate those interactions into changes to the underlying Model without requiring the team to manually maintain its structure.
This is inherently human-in-the-loop. Agents can perform mechanical tasks and propose changes, while the team provides the domain expertise, judgment, and validation required to determine what belongs in the Model and whether it is correct.
05
Eliminating Silos
A shared Model lets every team member understand their part in context — and see how changes affect the whole.
Once the team is working from a single version of truth, the Model becomes more than a shared data layer. Each person can work with Claude to understand their part of the domain in the context of the whole — ask questions, test assumptions, run scenarios, and see how a change in one part of the Model affects the rest. Because the data, relationships, and logic are connected, the team can explore the system together from the same underlying representation.
Different people do not need the same view of the Model. Each can work with the information, analysis, and processes relevant to their role while still working against the same underlying representation. The finance view, operating view, project view, or research view can be different without becoming separate versions of reality.
This becomes particularly useful when the parts of the domain interact. Change an assumption in one area and Claude can trace the dependencies to show what else is affected. Run a scenario and the implications can propagate across the Model rather than stopping at the edge of a spreadsheet. Ask a question about one part and the answer can incorporate its relationship to the rest.
The Model therefore becomes a shared environment for both individual and collective analysis. Each person can go deep on their part while Claude maintains the connections across the whole.
06
Secure Sandbox
A bounded environment for Claude and the Model.
The Proxa workspace operates inside a sandboxed environment. Claude and agents work with the Model through defined data, tools, permissions, and actions rather than receiving unrestricted access to everything connected to the domain.
Proxa does not need all of the raw data in the underlying systems and files. It identifies and encodes the information required by the Model, allowing source data to remain in place while exposing only what is necessary for analysis, modeling, and automation.
Within those boundaries, agents can analyze information, run calculations and scenarios, update the Model, and generate outputs. What they can access and what they can change is explicit, with the team guiding and validating the work.
The result is a controlled environment for increasingly capable AI: enough access and context to be useful, without requiring access to everything.
EXAMPLE
Diligence
A diligence process is a race to build an accurate model of a company under a deadline, from material that arrives in fragments: a data room, management decks, exports, calls, and third-party research.
The Domain Model becomes the working representation of the target — entities and ownership, revenue by segment and how each is defined, contracts and obligations, the assumptions behind management’s forecast and who made them.
Every workstream then draws on the same model. The commercial read, the financial model, the diligence checklist, and the investment memo resolve against one representation, so a correction lands once and propagates rather than being chased across five files.
When new material arrives, the model updates and the open questions narrow. What was verified, by whom, and when, remains visible.
EXAMPLE
Finance
Recurring financial work is the clearest case for a persistent model: the same close, the same reporting pack, the same forecast, month after month, with the reasoning rebuilt by hand every time.
The Domain Model holds the entity and account structure, each metric and its definition, the calculations, and the assumptions the forecast rests on — with an owner and a last-confirmed date on each.
Actuals flow in from the source systems. The model recomputes, exceptions surface, and the board pack, the variance commentary, and the updated forecast pull from the same current state.
Because dependencies are explicit, a changed assumption can be traced to everything it affects before anyone publishes a number.
EXAMPLE
Product
Product knowledge is unusually scattered: specs, roadmaps, research, tickets, analytics, and decisions taken in threads that nobody can find six weeks later.
The Domain Model represents the product itself — surfaces and features, the metrics that describe them, customer segments and their needs, and the decisions made with the reasoning attached.
That makes the roadmap answerable. What depends on this migration, what did we decide about this pricing question and why, which segment does this metric move — all resolve against the model rather than against whoever remembers.
Research and usage data keep it current, and the reports, reviews, and updates teams already produce draw from it.
EXAMPLE
Asset
An asset — a property, a fund position, a piece of infrastructure, a portfolio company — is held for years, and the reasoning about it accumulates in valuation models, reports, contracts, and correspondence that drift apart.
The Domain Model represents the asset itself: its structure and ownership, its cash flows and the drivers behind them, the terms and covenants that constrain it, the current valuation and the assumptions it rests on.
Operating data and third-party inputs keep it current, so a valuation is not a periodic reconstruction but a recomputation against a model that already knows what changed.
Reporting to owners, lenders, and committees then draws from one representation, and a question about performance resolves to structure rather than to whichever spreadsheet was opened last.
EXAMPLE
Sales
Sales information is spread across a CRM, notes, proposals, pricing approvals, and inboxes. The CRM records the shape of the pipeline; it does not hold the reasoning behind any given deal.
The Domain Model represents accounts and opportunities, the people involved and what each of them cares about, pricing and terms and what has been approved, competitive position, and the state of every commitment made.
Because the model is computational, pipeline questions can be answered rather than reported: what does this quarter look like if two renewals slip, which deals depend on a discount nobody has approved, where has the same objection appeared five times.
Forecasts, account plans, QBR material, and handovers to delivery all pull from the same current state.
EXAMPLE
Customer
Three sources hold most of what a company knows about a customer, and none of them agrees with the others. Contracts hold what was actually committed. Salesforce holds the commercial relationship. Customer success holds what is really happening.
Each is authoritative about something and silent about the rest. The contract knows the renewal date and the service levels but not that the account is unhappy. Salesforce knows the owner and the pipeline but not which entitlement was negotiated in an amendment. Success knows the sentiment but not the terms.
The Domain Model encodes all three into one representation of the customer: the entities and people, the commitments and their terms, what was bought and how it is used, open issues, renewal dates, and the decisions taken along the way — each fact carrying its source.
Then the question can be asked once. What did we commit to this account, what are we not delivering, what is at risk at renewal, and who owns it. The renewal conversation, the escalation, and the account review all start from the same facts.
The three sources keep feeding it, so the model is current without anyone reconciling three systems by hand.
EXAMPLE
People
Information about people is sensitive, fragmented, and unusually consequential: an HRIS, contracts, compensation reviews, performance notes, and org charts that are out of date the week they are drawn.
The Domain Model represents the organization as it actually works — roles and reporting lines, skills and responsibilities, compensation structure, and the decisions made about each, with permissions attached at the level of the model rather than the document.
That makes planning computational. What does this reorganization cost, which responsibilities become unowned, who is affected by a change to the leveling framework.
Access controls, observability, and audit matter more here than anywhere else, which is why they sit in the workspace rather than in the individual files.
EXAMPLE
All (an Org Model)
Each of these models is useful alone. Connected, they become an Org Model: a representation of the organization itself rather than of one function inside it.
The connections are where the value compounds. A customer commitment connects to a product dependency; a hiring plan connects to the forecast; an asset’s covenants connect to the finance calendar. Those relationships exist in reality and are usually held only in people’s heads.
Nothing about the approach changes at this scale. Each domain is modelled where the work is, the workspace keeps each one current, and the connections are made explicit as they matter — not designed up front in a two-year data programme.
The result is an organization that can be reasoned about: what depends on what, what changed, who owns it, and what a decision here does over there.
FAQ