Your data stays where you say.
On the Fund tier, Gyre runs as a single-tenant deploy. You choose the data residency. The engine is yours, not a slot on a shared cluster.
The Engine
The agent runtime that powers FulcrumGTM.
A rotating system in equilibrium. Built for persistent agents that survive tab close, hold complete context, and run with restraint.
A gyre is the physics term for a rotating system. The same one the gyroscope mark depicts. Fulcrum is the workspace, the gyroscope is the mark, the rotating system that keeps the workspace in equilibrium is Gyre. One metaphor, end to end. The brand is not a costume. The architecture earns the name.
What Gyre Does
The runtime is small on purpose. It does a few things deeply instead of many things shallowly. These are them.
Three tiers of memory across every session, deal, and account. Episodic memory captures what happened (the seller call from three weeks ago, the broker reply, the prior reasoning on this deal). Semantic memory captures domain facts that should never be re-derived (your thesis, your ICP, your fund's playbook). Procedural memory captures workflow patterns Alfred has refined over time.
The episodic and semantic tiers run on a vector store with hybrid retrieval. Procedural memory is governed by your tenant configuration so the agent's behavior reflects your operating model, not a default.
What this means in practice: Alfred remembers what the seller said in a call three weeks ago and uses it on Wednesday's email. Then on next month's QoE.
PDFs, shared-drive folders, audio uploads, and meeting transcripts are first-class inputs. Gyre extracts them, indexes them into deal context, and tracks version history so you can diff what changed when a CIM gets revised. Every document on the deal card is part of every analytical run, automatically.
The extraction layer handles tables, financial schedules, and embedded images, not just plain text. Reconciliation against accounting-system pulls is built in.
A native scheduler fires agent runs on cron, on event triggers, and on conditional rules. Periodic deal-card audits, daily marketplace scans, quarterly broker check-ins, weekly portfolio syncs. Run definitions are persisted, idempotent, and tenant-scoped.
The dispatcher is built on Postgres LISTEN/NOTIFY for low-latency fan-out from trigger to runtime, and the runtime is structured so individual agent runs can be resumed across process restarts. Long-running analyses survive tab close, deploys, and infrastructure changes.
Alfred runs in three output modes: Act on safe maintenance, Draft anything human-facing for approval, Propose any material state change for approval. The gate is architectural, not a setting. There is no configuration option that lets Alfred send external comms or alter material deal state without your approval. By design.
This is what makes the agent shippable. Not the model, not the tools, not the integrations. The discipline.
Every record carries a tenant identifier. Row-level security enforces the boundary at the database. Audit logs capture every agent action with attribution. The tenant configuration layer (a JSONB blob with each customer's persona, tool allowlists, slash-command vocabulary, and reasoning tier preferences) means the same engine ships verticalized configurations without code changes.
The architectural choice was made on day one, not retrofitted before a security review.
Why Gyre Lives Separately
Fulcrum is the workspace. Alfred is the agent persona. Gyre is the runtime. Three layers, intentionally separated.
What customers buy. Pipeline, Sourcing, Deal Room, integrations, channels, billing.
What customers talk to. The persona configured per tenant via prompt router and persona files.
What Alfred runs on. Runtime, memory, document grounding, scheduling, approval gate, isolation.
Separation lets the engine be hardened on its own cadence. New model providers, new memory backends, new tool surfaces can be integrated and tested at the engine layer without disrupting the workspace your team uses every day. Conversely, the workspace can evolve its UI, its surfaces, its integrations without forcing changes to the runtime contract.
For The Buyer
On the Fund tier, Gyre runs as a single-tenant deploy. You choose the data residency. The engine is yours, not a slot on a shared cluster.
Model upgrades, memory upgrades, tool additions ship at the runtime layer without disrupting the deal cards your team is mid-deal on.
The layered design is auditable, testable, and replaceable. If Gyre 2.0 changes the contract, you'll see the contract.
For Developers and Integrators
Gyre exposes an API for custom integrations, webhooks for event-driven workflows, and a tool-extension surface for funds and teams that want Alfred to call their proprietary data sources. Documentation is available under NDA for Fund-tier customers and partners.
If you're evaluating Gyre as the runtime for a vertical you want to ship, contact us. We've shipped two completely different verticals on the same engine already.
Fulcrum is the productized, hosted, multi-tenant offering. Gyre is the engine underneath. They're maintained as separate concerns so the engine can be hardened independently.
FulcrumGTM. Leverage and balance.