How we built an agentic operating system for a private-markets firm

What we built for a private-markets firm

A private-markets firm — running a book of direct investments, funds-of-funds, and treasury positions — replaced a spreadsheet-and-inbox operational stack with an agentic platform its team now uses every day through the channels they already lived in. Greelow designed and shipped the platform end to end.

The team can now:

• Ask portfolio, pipeline, and contact questions from chat or a web dashboard, and receive answers grounded in the firm's own tools and documents.
• Delegate scheduled and recurring work to the agent — reminders, briefings, follow-up detection — without those workflows depending on any single person's calendar.
• Share access selectively, so a partner's assistant can operate on the partner's fund inbox without gaining broader access, and so revoking a departing user removes every trace of their sessions in a single operation.
• Ask questions that span sources — a company that appears in a chat, a deck, and an invoice — and get one answer instead of three partial ones.

Every architectural claim below points at code we run for this client today. Enterprise agentic systems tend to fail in the same three places: identity, memory, and permission. The platform was designed around those three from day one, and the rest of the architecture followed.

The challenge

A private-markets team of fewer than twenty people was operating a portfolio in the low hundreds of positions across direct investments and funds. Their canonical data lived where it always had: a master spreadsheet, a workspace for pipeline and contacts, and their inboxes.

Nothing in that stack was broken enough to force a rewrite. All of it was slow enough to force a compromise. A portfolio update meant opening the spreadsheet, checking the workspace, scanning the inbox for the latest founder note, and reconciling by hand. New information often sat in one person's inbox until someone else asked about it.

They wanted to keep the spreadsheet as truth. Years of methodology sat in its formulas. But they wanted the daily surface to be a chat window. They wanted the system to know who each user was and to remember it across sessions. They wanted per-user boundaries that would satisfy their own governance posture. And they had no internal engineering team to build any of that.

Agents the team trusts with real work

The brief was specific. The platform had to reach a working state quickly, but every architectural decision had to survive years, because the firm has no plan to grow an internal engineering group.

Three constraints shaped every design choice.

The daily surface is chat. Not another SaaS UI. Every capability had to be reachable from the same messaging platforms the team already used, with a web dashboard for the surfaces that genuinely benefit from tables and charts.

The agent operates on real credentials. Not a shared service account. Audit trails, individual attribution, and per-user revocation had to be free consequences of the design, not features bolted on afterwards.

The agent must remember who each user is. Not just the last message. Who they are, how they work, and what they are focused on — durable, per-user, across conversations and across channels.

The solution

Per-user identity and per-user credentials

Every user brings their own credentials into the platform, and the system keeps them separate. The agent, when it acts on behalf of a user, acts with that user's authority and no one else's. Two users talking to the agent at the same time reach entirely disjoint credential sets.

Cross-user sharing is a first-class concept, not a workaround. A partner can share their fund inbox with an assistant, and the assistant's agent inherits that scoped access on the same code path as its own. A departing user is deprovisioned in a single operation that traces both directions of every share they were part of, so no stale access survives on either side.

None of this state is kept on disk. Multi-tenant systems that keep critical user information there tend to lose it. The platform refused to inherit that fragility. Dynamic state lives in the database. Local storage is treated strictly as a cache that can be rebuilt at any time. A new engineer joining the project inherits that discipline as the default pattern, not the anti-pattern.

The credential layer is where many enterprise pilots die. Teams hope to go live before someone from security asks to see the design. Getting the security answer first made every subsequent decision cheaper.

A catalog of small, domain-scoped tool servers

The agent reaches the firm's operational systems through the Model Context Protocol. Rather than one wide tool server, the platform exposes a catalog of narrow ones, each scoped to a single domain: finance, portfolio, document retrieval, invoicing, and so on.

The choice was deliberate. Narrow servers stay auditable. Each one receives only the credentials its domain requires, so a prompt injection that reaches one server cannot cross into another. Narrow servers evolve independently, without dragging every other domain into their release cycle. And narrow servers keep the per-user credential injection cheap: the builder for a small server is small.

A graph layer sits above the tool servers, resolving entities across sources. When a portfolio company appears in a chat thread, a pitch deck, and an invoice, all three references resolve to the same node. The team can then ask questions the underlying database could not answer cheaply — "which people appear in materials tied to portfolio companies of a particular fund" — without those questions turning into hand-written queries.

The database remains the source of truth. The graph is a derived layer that can be rebuilt from source at any time.

Two ways to schedule work

Agentic systems that only respond to messages waste half their value. The platform schedules work in two ways.

The platform's regular work runs on a scheduled cadence. Portfolio scoring, focus updates, daily and weekly briefs, incremental syncs from inbox and drive, matching people and companies across sources — each has a defined frequency and a defined scope. The scope is explicit: whether a task applies to all users, to a specific subset, or to the platform as a whole. There is one place to look to know what runs when.

Alongside the platform schedule, users can ask the agent to do things later. Plain language, no interface required. Remind me tomorrow at nine to call X. Every Monday, send me a summary of my inbox. Each request becomes a durable commitment the system honors when the time comes, and the system is designed so that two agents never touch the same user's session at the same time.

That last constraint was structural, not incidental. Two agents acting on one user's conversation at once would corrupt it. The design makes that collision impossible before it can happen.

A dedicated engine, not a bag of scripts

The engine that runs the agent — choosing which model to call, feeding it the right credentials, tracking what it has done, and shaping its results into something usable — is a coherent system, not an assortment of scripts. Everything else in the platform delegates into it. Three of its parts carry real weight.

The choice of model provider is separated from the rest of the system. When the platform needs the agent to think, it asks. The layer underneath figures out which provider to call. Swapping providers per user or per workload is a bounded change, not a rewrite.

A two-tier per-user memory solves the failure mode where the agent forgets who you are between conversations. A short-window episodic memory carries the recent past. A durable semantic layer carries who each user is and how they operate. The semantic layer is always present in the agent's prompt. The user does not have to re-explain themselves.

A domain-specific skill library gives the agent the vocabulary and workflows of private-markets finance. Fund administration, portfolio operations, investment analysis. The agent reasons in the firm's own language, not a generic one.

The outcome

The firm runs its day through the platform now. Portfolio, pipeline, contacts, and documents are reachable in a single conversation, from the channel each user prefers, with the agent operating on that user's real credentials and remembering who they are between sessions. Selective sharing lets partners give scoped access to assistants without opening broader permissions. Every deprovisioning removes every trace of a departed user in a single operation.

The system is what the firm calls theirs. Not because they wrote it, but because it operates on their canonical data, respects their governance posture, and speaks their vocabulary.

Quantitative outcomes for the firm's operations remain in observation. The system is young enough that the team is still measuring what changed. When the numbers come in, we will publish them on their own terms.

The platform is small enough that a new engineer can hold it in their head after a week. That is not an accident. It is a design constraint. What a team cannot hold in one head, that team cannot safely ship into.