Building Purrallel: from agent collaboration to verifiable delivery

An investigation needs a verifiable outcome#

Imagine you authorize a service security assessment. Its scope defines which systems may be examined, which actions are permitted, and what evidence is needed to confirm a finding. One agent examines authentication; another investigates a tenant-isolation hypothesis; a third tries to reproduce the behavior. You need to follow the work and decide what deserves further investigation.

Splitting the assessment helps, but introduces questions. Who may run a reproduction? Does a shared hypothesis already count as a vulnerability? Does a result belong to the current code revision? What happens if an agent loses access while working, or an operation’s response disappears after it has already finished?

We are building Purrallel to supervise that path: from an objective and authorized scope to a delivery accompanied by evidence, review, and traceable decisions. The example describes the intended experience. We have not demonstrated a complete autonomous production investigation. We can already test parts of the path, including failures that disappear inside an apparently successful conversation.

What Purrallel, Furrboard, and Purrlink are#

Purrallel is the larger system for supervising and executing agent work, aimed at software engineering and security research. Its intended user needs to delegate an activity while continuing to know what was authorized, what is running, and why a result may be accepted.

Furrboard maintains planning and work authority: projects, objectives, tasks, attempts, revisions, and acceptance criteria. A completed card alone does not prove an objective was met. We need to connect the result, artifact, revision, and acceptance decision.

Purrlink handles communication: session identity, recipients, routing, persistence when applicable, and message recovery. An engagement bounds the context of identity, data, and authorization. Projects inside it still need their own controls; sharing an engagement does not grant universal access.

Purrmind/context is the effort to organize knowledge with provenance and prepare context for agents. Contracts and components exist for versioned records, context packages, and handoffs. Parts of this integration remain unregistered in the runtime; that is not automatically shared memory available on every turn.

The harness bounds execution; Ferpa groups account and session components; Core supports the native client. They provide architectural context. This collection exercised libraries and local integrations without validating the entire operational composition of those components.

The same issue appears in software. Requesting a fix involves implementing, testing, reviewing, and integrating a specific revision. A passing test for an earlier commit does not establish the current change; the author’s persuasive response does not replace review. Verifiable delivery connects this case with a security investigation.

Why build another solution#

Parallelism, communication, and recovery already exist in the ecosystem. The references below are readings of official documentation, consulted on October 28, 2026. We did not execute these products to compare them with Purrallel, and we do not treat a protocol and a framework as equivalent products.

These capabilities can support solutions with controls similar to ours. They do not establish that Purrallel invented collaboration or that other systems cannot govern work. Our choice is to build a specific composition in which the domain retains authority even when the execution tool changes.

That has costs. We must maintain a protocol, persistence, migrations, and adapters; test their composition; and define who resolves uncertain state. A custom transport does not inherit A2A interoperability, and we have not demonstrated that compatibility. Existing protocols deserve evaluation as a need to integrate external agents emerges. The local trust boundary also matters: host checks assume its files and SQLite databases are protected. They do not isolate data from another process running as the same operating-system user.

For a short task, one agent with good tools may solve the problem with less structure. For an application that already fits a durable-execution framework, adopting its persistence may be a better choice. Purrallel exists to address the combined requirements we want for work supervision, rather than requiring a custom system for every use of agents.

Four choices guiding the implementation#

Work governed by evidence#

In an investigation, a hypothesis can be refuted and still produce a useful research delivery. We need to record what was tested and observed. Furrboard distinguishes objectives, tasks, attempts, and accepted Deliveries; the contract defines required evidence. Mandates bound delegated planning, and leases bind temporary authority to an attempt. Review and acceptance have their own requirements.

That makes “did the agent finish?” a more useful question: which attempt, on which artifact, with which decision? These are implementation choices, not evidence of global exclusivity. Autonomous composition of the entire lifecycle still requires its own validation.

Recoverable, bounded collaboration#

A message can arrive before the consumer persists its effect. Purrlink and its consumer therefore need to distinguish durable publication, received observation, and applied context. Effective identity comes from the trusted host, the process composing and authorizing calls; a participant does not select a more powerful role in its payload.

The value for an operator is being able to reconstruct what happened without treating a message’s existence as proof of an authorized transition. Replay, checkpoint, and revocation tests examine parts of that relationship.

Execution and resources under the same domain#

Before claiming work, an attempt must fit the configured limits. Reservation APIs check engagement, project, and provider limits and record the reservation alongside the assignment. Canceling or expiring a lease does not prove an external process stopped; releasing resources requires reconciling that effect.

Unknown costs remain unknown rather than becoming zero or new spending authority. Primitives and their own evidence exist for these components, but they do not establish actual billing, a complete operational supervisor, or an accepted multi-provider mission. CLI adapters and roles have separate activation gates.

Knowledge with provenance and portable context#

Sharing a summary does not make its contents verified facts. Knowledge components record versions, sources, and separate decisions about information. An old or out-of-scope reference cannot automatically become current context.

Context and handoff packages aim to preserve the task, criteria, evidence, versions, and uncertain effects. Preparing a package does not transfer a lease or resume another provider’s session. Existing projections format content; activating consumption, authorizing a new recipient, and continuing execution are separate steps. That boundary matters because portable information does not grant portable authority.

How agents communicate#

There are two layers: work organization defines authority; routes distribute context. In the imagined investigation, the conversation below uses invented identifiers and illustrative data. It is not a real execution transcript.

Direct addresses a specific recipient subject to current checks. RoleBus distributes to participants with a role inside the engagement; it does not establish project confidentiality. EngagementBus serves engagement channels, including presence. Not all that traffic is durable: presence is ephemeral.

In the exercised path, the session authenticates, the host authorizes the route, and the message is persisted when its kind requires durability. After receiving it, the consumer checks current authority, saves context in the checkpoint, and only then advances its applied cursor, the persisted position in history. Receiving Contract or Decision cannot change criteria, execute commands, or accept a Delivery.

The described collaboration integration accepts a bounded initial context batch. Restoring an attempt preserves its original checkpoint; it does not automatically inject every new message on every turn. An opaque artifact reference also triggers neither a fetch nor access permission. Those limits prevent presenting the channel as an unrestricted conversation that controls the system.

Four moments an interface can confuse#

In a local test, we sent an authorized command to create a goal in Furrboard. The domain recorded the mutation and its receipt. A synthetic SQLite trigger then caused persistence of the transport result message to fail. There was a real domain commit and a response that did not reach the caller. The communication error alone did not tell the client whether the goal had been created.

After restart, replay presented the operation again. Its original identifier let the domain recognize a retry and recover the receipt; the board revision stayed at one, without another logical mutation. A GetOperation query confirmed the outcome. Reusing the identifier with different arguments is a conflict, covered by domain tests. Recognizing the operation in Furrboard is distinct from deduplicating a message in Purrlink: work-state recovery cannot depend only on the transport deduplication window.

There are four distinct moments along this path:

An admission response (accepted) is not yet a durable acknowledgment (durable). Even the latter does not establish the other three rows. After reconnecting, the consumer needs its applied cursor: the position in history through which it persisted observations.

Another test persists the observation and checkpoint to a file and then simulates a lost reply from the persistence callback. The consumer is recreated from saved state. Its applied cursor follows that local commit; it does not advance merely because bytes arrived over a socket. This experiment covers recovery using on-disk state, but it does not establish durability under abrupt power loss.

More readers with the same publication workload#

To measure the message path, we kept two engagements, one publisher in each, and 500 RoleBus publications per engagement. The profile configures 25 ms between publications. We changed the reader count: 2, 25, 50, and 100 per engagement. Publishers, silent subscribers, and restricted identities complete the topology.

The harness opens sessions and publishes in one engagement before moving to the other. Its counter adds authenticated connections over the run; it does not measure a sustained concurrency plateau. Percentiles sample the 1,000 RoleBus publications, excluding Direct publications, duplicates, and denied attempts.

Each profile ran five times in fresh processes, using the same Release NativeAOT executable. A separate smoke checked setup and stayed outside the statistics. Accounting matters as much as the stopwatch: a fast run that delivers fewer messages would be a wrong result.

The p95 is the percentile at or below which at least 95% of that run’s samples fall. We calculated the median of five p95 values; brackets show their minimum and maximum. We did not pool raw latencies to calculate a global percentile, and this range is not a confidence interval. Harness output rounds timings to one tenth of a millisecond.

All twenty runs recorded 1,002 durable Acks, two recognized duplicates, two authorization denials, and two Direct deliveries. There were no foreign deliveries, unexpected errors, capacity rejections, or rate limits. RoleBus deliveries matched the expected count in every profile.

Measured time ends at durable acknowledgment. It does not measure when all readers consumed a message or when a task finished. Those 206 sessions are also not 206 agents performing inference. Memory is a final sample of the test process, collected after disposing its clients. It does not represent consumption during a plateau of active connections, a continuous peak, or server-only memory use. We did not collect p99. Because the workload is paced, this experiment does not seek the host’s maximum throughput.

Filling a queue is also a correctness test#

An unbounded queue lets a stalled consumer turn traffic into retained memory. Saturation behavior therefore belongs in the contract: admit a bounded amount, explicitly reject excess work, and preserve consumers that can still keep up.

The component benchmark separates the SQLite writer, which commits messages in batches, from outbound fanout, which distributes each message to multiple targets. The writer receives bursts that fill its admission queue before draining begins. Of 262,144 offered operations in the measured portion, 65,536 become durable messages in 512 batches; 196,608 are rejected immediately. The 75% rejection rate is a deliberate consequence of that construction.

For fanout, we offer 100,000 4-KiB frames to eight healthy targets and 120 silent ones. Healthy consumers drain their queues and must produce exactly 800,000 dequeues. A queue accepts 256 frames and refuses the 257th. After a real five-second grace period, all 120 silent queues must be removed.

These two rates use different measurement intervals. The writer uses its flush service window, including commit; fanout uses the offer loop, allocation, and healthy draining. Writer percentiles sample batches and omit queue residence. Fanout percentiles time the call. TLS, authorization, routing, and socket writes are outside this benchmark.

The 99.744% of operations marked Lagging count offers whose worst result encountered lagging targets; they do not mean that 99.744% of healthy deliveries were lost. Healthy delivery accounting continued to pass. That distinction keeps an isolated percentage from obscuring either a working protection or actual loss.

The first run remained the baseline. The next four passed the existing limits: throughput decrease of at most 20%, p95 growth of at most 25%, and rejection growth of at most five percentage points. We neither replaced the baseline nor adjusted limits. We also checked absolute variation between the first two runs. These are local regression limits; they do not establish a production service capacity.

Permission must remain valid during an operation#

Authenticating when a connection opens solves only part of the problem. A token can be revoked while traffic is flowing, and an authorization result computed before revocation can remain paused until close to the send. A test needs to reach that window rather than checking only a new connection with old credentials.

The fault-injection scenario (chaos) pauses an already computed validation result, revokes credentials, and publishes new markers before releasing that old validation. The markers let us ask whether an invalidated session received anything produced after the transition. Previously sent bytes cannot be recalled; consuming them late does not automatically establish a post-revocation disclosure.

We ran seeds 162, 177, and 211, which reproduce the choice of revoked readers, with 16 readers per engagement. Each run recorded a sampled maximum of 34 concurrent sessions, 16 revocations, one epoch change, and two denied reconnects. All three reports had zero foreign observations and zero forbidden deliveries, and clients using current credentials continued working. The epoch is the authorization policy generation: advancing it invalidates sessions from the previous generation. That change applies to the entire host.

A participant that ignores close also must not retain an authenticated slot indefinitely. Its removal passed the internal four-second assertion. We did not measure a revocation-latency distribution. Seeds reproduce test-scenario choices, not operating-system scheduling.

In Furrboard, the Chief may propose planning within an explicit mandate. A lease is temporary authority bound to a worker attempt. Separate tests race a proposal against revocation of that mandate and try to renew an old attempt after its lease expires and the task is reclaimed. The operation checks current authority again. In collaboration, typed messages containing accepted or approved enter as context; they grant no lease, review, or permission to mark work complete. The scenario reaches a submission In Review, not an accepted Delivery.

What exists and what remains#

We use four states: validated in the collection identifies cases measured or executed in this round; implemented component with its own evidence identifies code accompanied by documented tests or receipts outside this collection; planned indicates pending integration; not demonstrated marks a conclusion we cannot support.

Additional components were inspected at revision be6239db7d4496e386675d829672c91e3da96149. It differs from the benchmark revision described in the appendix. Historical architecture inventories do not replace later implementation and contracts; each statement needs an explicit scope.

The reason to build this foundation lies in the questions we want answered after delegation: did work respect scope? Does evidence match the reviewed artifact? Did an interruption repeat an effect? Did acceptance come from an authorized actor? Those answers must survive changes of messages and tools.

The next experiments should separate publication latency from time to consumption and measure a sustained concurrency plateau. Real networks, other platforms, and provider-backed execution extend that path. Full integration will need to preserve the same contracts rather than infer success from a conversation that ended well.

Appendix: environment, provenance, and reproduction#

The October 27, 2026 collection was local, with synthetic credentials and loopback TLS. Its original revision was 79022eef8a512093de91961dd0c094d58994568d.

The checkout advanced during collection. Final verification detected this: Purrlink sources and shared build inputs remained identical, and executable hashes matched those recorded before measurement. To resolve functional provenance, we repeated the 296 selected test cases and NativeAOT integration in an isolated copy of the original revision; all passed. Initial filters overlapped and were not added together as independent tests. External activity still prevents treating the machine as a quiet reference host.

The entry points used in the benchmark executable are small. Here, BENCH means the already published Release NativeAOT binary, and evidence/ is an existing directory with new output destinations:

"$BENCH" load --messages 500 --subscribers 100
"$BENCH" saturation --report evidence/run-1.json
"$BENCH" saturation --baseline evidence/run-1.json --report evidence/run-2.json
"$BENCH" chaos --seed 162 --readers 16 --report evidence/seed-162.json

We retained commands, per-run results, JSON receipts, TRX test reports, and hashes in the internal evidence package. This article uses aggregate data; those private records are not public downloads. We have not established high availability, distributed revocation, or power-loss durability.