Acropolis: A governed operational model of an organization.

A bigger model helps with fluency and nothing else, and it carries a cost the market hides: to understand the company, it has to be shown the company. Every document, thread and customer record goes out to whoever runs the model, and what comes back is an answer, not an asset.

Acropolis keeps the understanding in a record the company owns. Frontier models fill seats around it.

The system under test has three model seats. The understanding seat builds the record. The retrieval seat rewrites the question and ranks the evidence. The answer seat composes the reply from the evidence envelope. The experiment swaps models between those seats and measures what moves.

Every row was run with the understanding seat on Gemma-4-31B, an open-weight model on one GPU, with local embeddings. “Local” here means ownership and operation, not machine location: an open-weight checkpoint served under our own control, with no inference sent to a model-provider API.

Each column builds the record the same way – the open-weight model on one GPU, local embeddings, local retrieval. What differs is who answers. Figures are the share of the all-frontier reference on each benchmark: strict per-question accuracy, a fixed judge, full question sets.

Under BEAM’s own rubric protocol the rented-thinking placement, 66.4, is within noise of frontier in every seat, 66.8.

The recommended default is the middle column, not the left one. The company builds and holds the record on hardware it owns, and rents a frontier model only for per-question answering – the one seat the experiment shows is worth renting. Fully local is the right answer for a perimeter that admits nothing, and it is a placement with a measured price, not the aspirational best.

That price includes latency. On BEAM 100K the fully local rows ran at a median of 12 to 15 minutes per question at benchmark concurrency, against under a minute for the frontier rows, because the synthesis prompts run near 57,000 tokens. That is a throughput figure on a shared benchmark box, not a single-user latency – but a reader who deploys fully local should know it before, not after.

An agent with credentials can read the wiki, the tracker, the CRM and two years of chat history. None of that tells it who owns a decision, what was tried last quarter, which of two contradictory documents is current, or what it is allowed to do with what it has just read.

Documents and databases describe pieces of a company. They do not represent how the company currently operates.

So each agent reconstructs the organization for itself, out of whatever it can retrieve in the moment. Every agent ends up with a slightly different company, none of those versions is complete, and none of them outlives the session that built it.

Nearby systems – including formations, software factories, etc. – connect through defined interfaces. They do not become hidden super-agents with broad access to the company.

Results return as attributable outcomes: events with a source, time and scope. They can update the operational model, but the execution layer cannot rewrite history.

“The system found nothing” and “the system holds no concept of this” are different answers, and callers can tell them apart. Absence is labeled, never silent – which is what makes an abstention column possible at all.

We measured what that column is worth by removing it. One labeled probe contract, run once on our own substrate and paired against the shipping contract on identical questions: instructed never to say the information is missing, the same system scored 87.2 against 88.0 with the refusal intact, and turned 30 refusals into 30 fabrications. Scored on answerable questions only – the way never-refuse systems report – the same answers read 92.8. The refusal buys nothing on the headline and everything on the guard column.

The AI never decides what it’s allowed to see.

Retrieval, authorization and coverage accounting are deterministic code paths that run before any model is called. The model composes from an evidence envelope; it never decides what it was allowed to see. Acropolis does not retrieve unauthorized information into an agent’s context and then ask the model to behave correctly.

The difference is architectural rather than a matter of better instructions. A policy that lives in a prompt is a request to a probabilistic system. A policy that lives below the model is a property of the retrieval path, and it holds whether or not the model cooperates.

One precision matters here. What the model sees is decided before it runs. Whether it asserts beyond that envelope is a contract instruction, not a hard gate – and its compliance is what the guard columns in the evidence section measure. This page does not claim a gate where the paper describes an instruction.

The entire Acropolis stack runs within infrastructure you control – inside your cloud environment, network and security perimeter. Your operational data, knowledge, telemetry and AI interactions do not need to leave it.

There is no VarOps-hosted Acropolis service and no external control plane. Nothing is transmitted to us automatically – no telemetry pipeline, no phone-home, no background reporting.

Acropolis writes operational telemetry – latency, error rates, query volume, source coverage – to storage inside your environment. It stays there. When we need to investigate something, we log into your environment through your VPN using credentials you issue, and review it there, the same way any service provider would. Nothing is copied out.

You control:

Instead of sending sensitive company data to another SaaS platform and relying on that vendor to protect it, Acropolis brings the intelligence to where your data already lives. The only data that leaves your perimeter is what you send to an external model provider, if you choose to use one.

The core company-brain components carry almost no third-party dependencies, which is what keeps the software supply-chain surface small. Components such as MUXI that do rely on third-party packages follow a dedicated dependency monitoring and maintenance process.

Source code access for independent security assessment can be made available under NDA as part of procurement, alongside architecture review and supporting security documentation.

Every Acropolis component starts with a verb.

Varys observes. Hero executes. Eunomia governs. Pythia answers. Ariadne reaches. These are actors.

Parthenon holds the operational model. Acropolis contains the system around it. These are places.

The system is Greek-led, but the names are not decoration. Varys is not Greek. What matters is that Varys is a person’s name attached to something that acts. The rule serves the architecture, not the other way around.

Sometimes a name proves that a design is wrong. That happened with Iris and Propylaea: writing down their verbs showed that a responsibility had crossed the wrong boundary. We changed the design instead of defending the name.

The rule also works in the other direction. Pythia answers and does nothing else – her only tools are asking questions, computing over the answers and extracting from them. The name arrived after the constraint, not before it.

That is what the names are for. They give us a simple test: does each part have one clear job, and is it the right kind of job?

The result, drawn once:

The top of the diagram is the approved company systems: tools, conversations, meetings and identity sources. They provide evidence about how work happens. The bottom is the people that work gets done for, and their machines. Everything between them has one clear job and a boundary it cannot cross.

An agent connected to Acropolis does not receive a copy of the company’s memory. It does not get a huge prompt containing everything the system knows. It receives task-scoped context: the smallest approved set of constraints and facts needed for the task.

This happens in two stages.

Before planning: ask what constrains the task

Standing constraints that apply to many tasks – such as accessibility needs, firm restrictions and standing policies – are carried in ambient memory. They are available before the agent asks a question.

Hero uses the user’s objective, the available tools and the task to create a short list of questions. Only those questions go to Parthenon. The objective itself stays with Hero, which preserves the boundary between memory and execution.

Parthenon answers them through one batched request, ask_batch. The batch uses one canonical snapshot of company state, one authorization decision and one shared retrieval budget. In plain terms: every answer comes from the same version of the company, under the same access check and within the same search limit.

After candidates exist: ask about the specific entities

The second request happens after the agent has identified the people, systems, suppliers, places or other items involved in the task.

It then makes a deterministic lookup: context(subjects). This fetches recorded context for those exact names. It cannot happen in the first stage because the candidates do not exist yet. Keeping the two operations separate also makes their different cost and scope clear.

Absence is part of the answer

“Nothing came back” is not precise enough for an agent that may take action.

Every answer includes a coverage status – answered, searched-and-empty or outside-the-ontology, the states the coverage section above is about. Restricted information does not reveal its existence to someone without access.

Each batch also carries a validity token tied to the Knowledge Change Log. Hero can reuse the result and compare the token with the latest checkpoint. It does not have to guess when cached information has expired. If the underlying state changed, the agent knows it must check again.

Consider a request to find a place for a team dinner. Known allergies and accessibility needs are already available. Before planning, the agent asks what else limits the task. Once it has a list of venues, it asks what Acropolis knows about those places. It never needed a fixed instruction saying, “If the task is a restaurant, remember dietary preferences.”

Some questions have no stored answer

“How long since we last heard from them” is not in the brain. Neither is “how many are still open” or “is there anything we’ve missed.” These get routed to Pythia, the answering agent, who can only do three things: ask Parthenon questions, compute over what comes back, and extract from it. She has no other tools and cannot acquire any. She reaches Parthenon through the same public read surface as any other caller, in front of the access checks rather than behind them, so a question she asks on your behalf sees exactly what you would see.

A mis-route costs nothing. A question that turns out to be a plain lookup collapses to a single ask, and the stated fact passes through unchanged.

This makes memory useful without asking it to plan the task, act on the company or grant permission.

A company has:

• facts that change;
• facts that conflict;
• temporal truth – what was true at a given time;
• supersession – which decision or fact replaced an earlier one;
• people, roles and relationships;
• provenance – the source and evidence trail behind a claim;
• scope and permissions; and
• derived state – facts calculated from other facts – and current state.

Retrieval can find the sentence that says Sarah approves invoices. Operational memory has to answer a harder question.

That is why memory must track state, not just retrieve text.

Public memory benchmarks score one thing: Can a system find the right piece of history and answer a question about it.

Acropolis does that. It also watches the systems the company already runs on, holds what it learns as a brain the company owns, decides who is allowed to see what before an answer is composed, works out answers that were never written down, acts in the channels people already use, and reaches the desktop.

The tests below score one part of that. We publish them because that part has to be sound before any of the rest is worth anything.

For each test, we report both search quality and final answer quality. A single score should not hide whether Acropolis found the right evidence, ranked it well, gave the right answer or chose not to answer when evidence was missing.

Three configurations, reported separately.

Core is Parthenon answering directly: the question goes to the store, the store returns what it holds. Agentic adds Pythia, who can ask several questions and compute over the answers before responding. Agentic with frontier escalation adds one more step, and it fires only on the system's own refusals: when the agentic path declines to answer, the question goes to a frontier model rather than coming back empty.

Some questions only need the first. Reporting them together would hide which kind of question each benchmark is actually testing.

Since the September run, each card also carries the placement rows: the same tests with a local open-weight model in every seat, and with a frontier model rented for the answer seat alone. Those rows are single full runs, read at the paper's noise floor – a one-to-two-point difference is a hold, not a win.

The design case is the same in all three, and the seven principles above are the whole of it. What changes from benchmark to benchmark is which of them carries the weight, so that is what each panel names.

A system instructed never to say "I don't know" cannot lose a point for making something up. That protocol is real, it is published, and on one of these tests it produces a higher overall number than ours. A commercial memory layer publishes 98.0 on LongMemEval-S under it. Thirty of the 500 questions are unanswerable traps, correct only when refused, so a never-refuse system caps at 94.0 under the official rule – a score of 98.0 cannot have been produced under that rule.

We measured the size of that difference on our own substrate rather than estimating it. Under a never-refuse contract, the same brains, retrieval and judge score 87.2 on all 500 and 92.8 on the 470 answerable ones. The bridge from a published never-refuse number to ours has three parts: answerable-only scoring, a judge that does not see fabrications, and whatever model or retrieval difference remains.

We count refusals as refusals. We publish the columns that show what that costs and what it buys.

Within three points overall of a system that never refuses – while refusing what should be refused. Twenty-six points ahead on contradiction handling, and it knows when it does not know.

The composite is a shipping configuration, not a post-hoc selection. The routing policy is fixed before the run. Ship the cheap pass's refusals and conflict declarations, use frontier synthesis otherwise.

The methodology appendix carries the full account: dataset hashes, model pins, judge prompts, retrieval budgets, aggregation formulas, the noise floor and the dated corrections log, plus the per-question run reports behind every figure above. It publishes with the paper.

These scores show how one setup performed on specific tests. No benchmark covers every part of company memory. The results also do not prove that Acropolis is “the best” with every model, workload and test method. That claim would need much broader evidence.

Zero submissions quarantined on the clean run. No embedding vendor and no GPU in those machines. Local tokens are priced at the frontier list rate in every cost figure, so the rows are comparable – the real local cost is GPU time, and the paper reports it as latency.

One line from the paper is worth keeping. Distillation is deliberately lossy, and the system still puts the right evidence in the top ten on 99.8% of LongMemEval questions. Compression that keeps the answer is a system property, not a retrieval trick.

The operational model, search indexes, identities, policies and execution tools stay inside the client-controlled environment.

When inference must stay local, tuned LLMs can run on consumer hardware. Inference is the step where a model processes a request and produces an answer. A full local setup falls in a hardware class below $100,000, depending on the workload, number of users and backup needs. It does not require a seven-figure GPU cluster or permanent use of the most expensive models.

The benchmark tests run on local Nomic embeddings throughout. The August figures used low-cost LLMs; the September campaign ran an open-weight 31B model in every model seat on one GPU per bench machine, with a frontier model rented per question in the rent-the-thinking rows. The scores do not depend on sending the full history to a frontier model and asking it to solve the memory problem by force.

Data is not placed in one shared pool with a permission check at the end. RBAC segregation applies when data is stored, retrieved and assembled into context, so data from one role, agent or workflow cannot leak into another.

• Fixtures, not live organizations. All identity, permission and task-scoped results are measured on controlled fixtures – a generated organization of 1,000 people, a synthetic directory, scripted changes – not on a live company’s directory under operational load.
• The datasets are not enterprise-shaped. All three are conversational-memory benchmarks, chosen because they are public, reproducible and already used by the systems we compare against. No corpus or question was authored by VarOps.
• One model, one GPU class. The local placement was measured on one open-weight model on one GPU class. No claim is made about other models or smaller hardware.
• Two negative results, reported rather than buried. A local cross-encoder reranker was predicted to close the local retrieval gap and widened it instead: Hit@5 52.5 against 80.6 for the local language model on the same pool. Prompt contracts written against observed failures did not move scores: 73.0 to 72.2 and 79.6 to 77.6 on paired full runs, with the refusal count unchanged.

These are the next validation steps, not assumed capabilities – and they are worth treating that way when pricing risk and rollout.

We built Acropolis and the wider stack because the available tools were not good enough for the work our clients needed.

Agent frameworks were not built for company-scale systems. We built MUXI. Giving every agent the same broad access was unsafe. We built agents with role-based access control. Engineering teams needed a way to coordinate and control many coding agents. We built Cloop, an engineering control plane. Most agent systems treated email as an add-on. We built Emailgent, email designed for agents.

Most memory systems stored chunks of text and searched them later. We needed a reliable model of the company’s current state, so we built Acropolis. These are not separate side projects. They come from one engineering principle, applied across a stack that has taken two years to build: when the basic design is wrong, another integration will not fix it.

Acropolis is installed as part of a VarOps engagement. It runs on the client’s hardware and follows the client’s access rules, and we understand the system down to its boundaries because we built it. It is not a separate software purchase, and we do not force it into work where it does not belong.