The context and tool layer for agent systems.
Pylee gives agents shared task state and approved MCP tool access, so teams can coordinate reliable workflows across agents, services, and partners.
Keep context, secrets, server configuration, and access rules in one controlled layer, instead of spread across prompts, clients, databases, and ad hoc glue code.
Agent workflows need shared state and controlled access.
Agent workflows break down when task state lives in prompts, logs, databases, client configuration, and ad hoc integration code.
Pylee gives each workflow a shared context with access rules built in. Internal agents, outside services, partner systems, and reviewers can coordinate through the same task state while each receives the right view of the work.
The same control model applies to tools. Teams can approve MCP servers, manage secrets, pin versions, and decide which agents or services can access each tool.
Describe, but don't enforce
Prompts can describe who should see what. They do not enforce access control.
MCP setup spread across clients
Server configuration, secrets, and versions repeated in every client. Hard to keep approved or current.
Storage without coordination
A database stores state. Scoped reads, patch updates, leases, conflict handling, and history still have to be built around it.
Coordinate workflows with shared task state.
Pylee Context gives each workflow a structured JSON context that agents, services, tools, reviewers, and trusted outside systems can share. Each participant gets access to only the sections it needs.
Structured task state
Each task has one JSON document, organized into named sections such as inputs, planner, validator, and summary. Patch updates replace full document writes.
Section level access control
Actors can be granted read or write access to specific sections. Responses are filtered by the service before they reach the client, so clients are not responsible for filtering shared state correctly on their own.
Leases & version checks
Agents can acquire time limited exclusive access to one or more sections while they work. Writes can include an expected version, so concurrent updates do not silently overwrite each other.
Event history
Reads, writes, deletes, and ACL changes are recorded with actor, timestamp, section, and operation metadata.
Storage backends
Same logical API across SQLite, Postgres, Redis, and in memory storage. Designed to run with storage you control.
HTTP and MCP.
A REST API for direct integration, plus an MCP server (stdio or streamable HTTP) for agents and hosts that already speak MCP. Same core operations, both transports.
Manage the MCP servers your agents can use.
Pylee Registry gives teams one place to organize MCP servers and expose approved tools to MCP compatible clients. Configure once, distribute everywhere.
Instead of configuring every MCP server separately in every client, teams manage configuration, secrets, versions, and access from one place. Agents and services connect through Pylee and receive only the tools they are allowed to use.
Private registries
Organize MCP servers by team, project, environment, or use case.
Shared configuration
Manage server settings once instead of repeating them across clients. Updates roll out to every connected agent.
Secrets management
Store API keys and environment variables centrally, then inject at runtime. Secrets stay out of client config.
Version control
Pin teams to approved server versions until a new version is reviewed and released.
Access control
Decide which users, teams, agents, services, or clients can use which servers, enforced at the registry boundary.
One connection point.
Connect Claude, Cursor, Codex, VS Code, or any MCP compatible client through one endpoint. Pylee routes each client to the servers it has been granted, with the right config and secrets attached.
One context, different views.
A planning agent writes a proposed plan to the task context. A validation agent reviews the plan through its permitted view. An external service checks selected fields and writes back a limited result. A summary agent prepares the reviewer view.
# One agent writes, with version check PATCH /api/v1/contexts/ctx_01914f… x-actor-id: org_acme:agent:planner { "patch": [{ "op": "replace", "path": "/planner/status", "value": "complete" }], "expectedVersion": 3 } → 200 OK // version=4
# Another agent reads: ACLs scope the response GET /api/v1/contexts/ctx_01914f… x-actor-id: org_acme:agent:validator → { "planner": { "status": "complete", "result": "..." }, // planner.scratchpad filtered by service "_meta": { "visibleSections": ["planner", "validator"], "partial": true } }
What's happening here
-
Qualified actor IDs:
orgId:type:nameidentifies who is making the call. Pylee uses this to evaluate access. -
Version checks:
expectedVersion: 3means the write fails if someone else advanced the context. Concurrent updates do not silently overwrite each other. - Service side filtering: the validator does not see the planner's scratchpad. The response is shaped before it leaves the service.
-
Honest
_meta:partial: truetells the caller the response was filtered, so they know they are seeing a scoped view.
Not an agent framework. The layer around the choices you make.
Pylee does not decide how agents plan, route work, choose models, or call tools. It provides the context and tool access layer around those choices.
Use it with what you already have.
LangGraph, CrewAI, AutoGen, custom orchestrators, raw model calls, MCP clients, or plain HTTP. Pylee plugs in alongside.
Different actors, different views.
The same task context appears differently to a planner, a validator, a summary writer, and a reviewer, with no client side filtering required.
Workflows that cross things.
Multi agent workflows that span services, partners, or tools need a shared place to coordinate. In process memory stops being enough.
State you can hand to an auditor.
Section level access, an event history of every operation, and secrets behind service boundaries for teams where "who saw what, when" is a real question.
Built for teams moving beyond single agent prototypes.
Different teams adopt different parts of Pylee depending on what they're building. The pieces compose.
Context, Registry, or both.
Use either service on its own, or use them together when workflows need both shared state and approved tools.
Pylee Context
Coordinates the state of the work with scoped access, patch updates, version checks, leases, and event history.
Pylee Registry
Controls the tools available to that work, including approved MCP servers, secrets, versions, configuration, and access.
Common questions.
Is Pylee an agent framework?
Do I need both Context and Registry?
Can Pylee coordinate with agents or services outside my organization?
Why not just use a database for context?
Why not configure MCP servers directly in each client?
Can I run it in my own infrastructure?
Build reliable agent workflows with shared context and approved tools.
Use Pylee Context for shared task state, scoped access, leases, versioned updates, and event history. Use Pylee Registry for MCP servers, secrets, versions, configuration, and access.