A context backend for AI agents.

Agents are clients of the context, not its owners.

Fulcra is a user-owned context backend. It stores structured records, time series, files, shared data and agent work in a durable context lake that stays separate from any particular model, agent, application or AI provider.

Application databases are scoped to applications, and agent memories to agents. Fulcra is scoped to the owner: it holds context belonging to a person or organization and makes it available across compatible agents and applications.

Paste this to your agent
Copy
https://docs.fulcradynamics.com/agent-get-started.txt
Agent guidance (llms.txt)Platform concepts

CAPABILITIES

What a session cannot hold.

Three things session context cannot reliably provide. For the user, context survives changes in agents and applications without becoming captive to any of them.

Continuity

Build on context accumulated by prior sessions, applications and agents — then leave durable results for the ones that come after.

Freshness

Discover what changed since the previous loop, instead of asking the user to reconstruct the current state.

Synthesis

Work across live and historical data, recorded knowledge, files and agent outputs that would otherwise stay fragmented across applications.

Agent onboarding →Groups →

PATTERNS

An architectural primitive.

Four ways to build on it: separate agents from source systems, react to change, coordinate through shared state, and preserve context across replaceable software.

Context Boundary — give agents context, not credentials

Populate Fulcra through deterministic or user-authorized ingestion, and let agents find, read and add to the result without touching the source systems. Ingestion defines the boundary; the sources stay authoritative. Inside it an agent works without credentials to every upstream system — external actions still go through separately authorized tools.

Feed-Driven Reactive Loop — every loop starts with what changed

Ask for an update summary from your last successful watermark, see which types or files changed, retrieve just those, respond, write back, advance the watermark. Reactivity is bounded by ingestion — an agent reacts only to sources that flow in. Once they do, it asks Fulcra once instead of polling every source. Incremental discovery, not push delivery or a job queue.

Shared Blackboard — agents coordinate through context

Publish typed facts, requests, status, partial results, decisions and artifacts; other agents find them through update summaries and queries and add their own. Asynchronous shared state rather than agent-to-agent RPC — nobody needs an address or has to be awake at the same time. Add a queue when you need exclusive claiming, strict ordering or exactly-once execution.

Durable Owner Context — applications and agents are replaceable

Put whatever should outlive an application, an agent profile or a model into Fulcra. The application database keeps running application state; Fulcra keeps the owner's longitudinal records, files and accumulated agent work. Regenerated software and new agents pick up the existing context instead of starting over.

Data model and primitives →

BOUNDARIES

Durable context, not the whole runtime.

A memory system decides what an agent retains; Fulcra is the wider owner-controlled context memories can sit in, and prescribes no retrieval policy. An application database runs an application's state; Fulcra holds what should outlive it. A lakehouse stays authoritative; Fulcra holds an agent-facing working set beside it. A queue gives claims, leases and exactly-once execution; Fulcra's updates support discovery and coordination, not those guarantees.

OpenAPI specification →Python client →

If all relevant context is transient, already present in the request, and has no value beyond the current agent or application, Fulcra adds little.