A living model of your organization.

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.

Agents do not independently reconstruct the company. They operate against this shared model, and they inherit whatever it currently says.

Acropolis acts as the control plane between an organization and the AI systems operating on its behalf.

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.

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.

Acropolis does not retrieve unauthorized information into an agent’s context and then ask the model to behave correctly. Authorization is enforced before information reaches the model.

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.

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.

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 entity lookup: context(entities=[...]). 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, no_type_in_brain or budget_exhausted. This tells Hero whether it found an answer, searched and found nothing, lacks that type of knowledge, or ran out of retrieval budget. 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 two things: ask Parthenon questions, and compute over what comes back. 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.

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 and computing over the answers. 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?

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.

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.

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

Within three points of a system that never refuses – while refusing what should be refused. Roughly 1.74× as likely to catch a contradiction, 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.

Every question resolves to a stated coverage state. Answered, searched and found nothing, or outside what the brain holds. "We have no record of that" and "that is not something this firm tracks" are different answers, and the person asking can tell them apart.

The final method will use the exact definitions from the test software. If a metric does not apply to a benchmark, we will mark it N/A and explain why rather than leave it out.

Every published result will include:

• the exact dataset version, number of questions and any exclusions;
• how data was loaded and split into sessions;
• the reader, extractor, embedding, reranker and judge models;
• prompts, search limits and context limits;
• scoring rules, number of runs and variation between runs;
• baselines, speed, token use and cost;
• errors, manual changes, ablation tests and known limits; and
• the test software, or enough settings to reproduce the run.

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.

Anything authorized can query the model: coding agents, assistants, scheduled jobs, and the tools people already work in. What they inherit is not a document set. It is the organization as the model currently holds it, bounded by what the caller is allowed to see.

That makes a class of question answerable that retrieval alone cannot settle. These are illustrations rather than features:

• Who owns this?
• What happened before?
• What changed?
• What is the current state?
• What am I allowed to see?
• What am I allowed to do?

The last two are answered the same way as the first four, by the model rather than by the agent, which is what keeps the answer consistent between one agent and the next.

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 can cost less than $50,000 in hardware, 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 current LongMemEval-S, LoCoMo and BEAM 1M tests use local Nomic embeddings and low-cost LLMs. 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.

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. We understand the system down to its boundaries because we built it.

We do not bundle third-party SaaS products and call that transformation. We also do not force Acropolis into work where it does not belong.

Acropolis is not a separate software purchase. The technology exists to make the engagement better, not to create another product line.