JarvisCore Goes Open Source: A Masterless P2P Multi-Agent Framework

A Python AI agent framework that has been running in production for several months has been released as open source under the Apache 2.0 license. It's called JarvisCore, developed by the Prescott Data team, and its core positioning is a Python framework for building AI agent teams. What makes this project stand out is its deliberate rejection of the "orchestrator" architecture so common in today's multi-agent systems, opting instead for a peer-to-peer (P2P) mesh network design.

For developers building multi-agent systems, frameworks forged in real production workloads are often more valuable than those designed on paper — their architectural trade-offs reflect exactly the "boring" failures that give engineers headaches.

No Master Controller: All Agents Are Equal

Most multi-agent frameworks rely on an "orchestrator" or "master agent" to assign tasks and coordinate workflows. JarvisCore takes a different approach: all agents are peer nodes, forming a P2P mesh network where they send requests directly to one another with no central dispatcher.

Technically, membership discovery and health checking are handled by the SWIM gossip protocol — a mature, decentralized membership management solution from the distributed systems world, where nodes maintain a cluster view through random probing and gossip propagation. Applying this to agent collaboration means node joins, departures, and failure detection all function without a single point of failure.

The maintainer openly posed an honest question in their post: they want to hear from people who have built multi-agent systems about where the "no-orchestrator" approach will break down. This is actually a critical issue — decentralization brings resilience, but can also introduce new challenges around global consistency, task deduplication, and orchestrating complex dependencies. This open attitude is more trustworthy than the polished marketing of many projects.

The SWIM (Scalable Weakly-consistent Infection-style Membership) protocol was proposed by Cornell University in 2002, originally designed to address scalability issues in large-scale distributed system membership management. Traditional heartbeat-based approaches require each node to periodically send messages to all other nodes, with communication overhead growing quadratically with node count. SWIM reduces this to near-linear complexity by randomly selecting a small number of nodes to probe (ping), then disseminating state changes to all members via epidemic-style (gossip) propagation. The protocol is used in mainstream distributed systems including Consul, Serf, and Cassandra. Applying it to AI agent clusters means that when a new agent comes online or a node crashes, the entire mesh can automatically detect and update its topology without any central node involvement — the foundation of P2P architectural resilience. However, this also means cluster state is "eventually consistent" rather than strongly consistent, requiring additional design for scenarios that demand globally atomic decisions.

Tools Are Self-Written, No MCP Server Required

JarvisCore's second distinguishing feature is that it requires no MCP server. In the current ecosystem, MCP (Model Context Protocol) is becoming a popular standard for connecting tools to models, but this framework takes a different path: agents write their own tools, run them in a sandbox, and save working functions to a registry for reuse.

This registry comes pre-loaded with approximately 1,200 functions covering 150 service providers, essentially giving agents a ready-to-call capability library out of the box. Complementing this is a credential broker that injects credentials only at the moment of invocation — decoupling key management from tool execution, which is a sensible design from a security standpoint.

The chain of "self-written tools + sandbox execution + registry reuse" is essentially giving agents a degree of self-extension capability, while using the sandbox and credential broker to keep risk boundaries under control.

MCP (Model Context Protocol) is an open protocol introduced by Anthropic in late 2024, designed to provide a standardized connection interface between large language models and external tools and data sources — analogous to USB-C for hardware peripherals. The benefit of MCP is that tool implementations are decoupled from model invocations, and the same MCP server can be reused across different agent frameworks. The trade-off is maintaining a separately running server process and bearing the additional complexity of protocol version compatibility and network communication. JarvisCore's choice to bypass MCP and have agents generate and execute Python functions within a sandbox is a "self-sufficient" trade-off: it reduces external dependencies, but means that the quality and security of tools are entirely backed by the framework's own sandbox mechanism, placing higher demands on the rigor of sandbox isolation.

Bounded Memory: No Silent Context Truncation

What truly reflects this framework's "born in production" origins is its approach to memory management. The maintainer is candid that agent frameworks often fail in the "boring" places:

• Context being silently truncated
• Tasks sending false "done" signals when they haven't actually completed
• History quietly disappearing

JarvisCore's approach is bounded memory that never silently truncates. Old context is summarized based on real evidence, with original content archived and preserved, and lossy summaries are explicitly labeled as such. In other words, the system doesn't pretend to remember everything — it honestly tells you what has been compressed and what can be traced back to the original.

This insistence on "making information loss transparent" is exactly the kind of problem that only gets surfaced and prioritized when running real workloads over time. The maintainer notes that most of these bugs were found while running real workloads, and that the fixes, issue tracking, and underlying reasoning are all publicly available in the issue tracker.

Open Source Model and Candor About the CLA

On the topic of business model, the maintainer is refreshingly transparent and doesn't sidestep controversy:

• The core is Apache 2.0 licensed — this repository is the complete open source core
• Some enterprise-hardened features are in a separate commercial distribution
• Contributing code requires signing a CLA (Contributor License Agreement) so that contributions can be included in both the open source and enterprise versions

CLAs have always been a contentious topic in the open source community — they give maintainers the right to use community contributions in commercial versions, and some developers feel strongly about this. To the maintainer's credit, they addressed this directly and expressed willingness to discuss it, rather than burying it in fine print.

This combination of "open core" plus CLA is increasingly common in commercialized open source projects. Whether to accept it depends on each contributor's personal values.

A CLA (Contributor License Agreement) requires external contributors to grant the project owner certain usage rights over their code, typically including the right to relicense contributions under a commercial license. This differs from pure open source licenses (such as Apache 2.0 itself) — the latter only defines downstream user rights, while a CLA additionally specifies the rights transferred between upstream contributors and the project. Opponents argue that CLAs are fundamentally an unequal arrangement of "community contributes, company profits," and organizations like Mozilla and the Python Software Foundation have switched to DCO (Developer Certificate of Origin) as a lighter-weight alternative. Proponents argue that CLAs are a necessary safeguard for commercial companies to sustain long-term open source investment. For contributors, the key questions before signing are: does the CLA allow contributors to retain full rights to their own code, and does the existence of a commercial version align with their own open source values?

Where the Project Needs Help Most

As a project actively seeking contributors and real-world feedback, the maintainer has outlined several priority areas:

• Documentation clarity, along with examples that have clearly defined expected outputs
• Test coverage: workflow recovery, message routing, node discovery
• Bug reports with minimal reproductions
• Tasks tagged good first issue and help wanted for onboarding

For developers looking to get involved in open source multi-agent projects, this is an accessible entry point. For teams evaluating technical approaches, JarvisCore's design trade-offs — the decentralized P2P mesh, autonomous tool generation, transparent memory management — are all worth examining, especially the engineering ethos of "fixing real bugs in public" that underpins it all.

Repository: github.com/Prescott-Data/jarviscore-framework. It should be noted that this article is based on the project maintainer's self-description on Reddit, and relevant performance and stability claims remain to be further validated by the community.