Skip to content
PlanRelayPlanRelay
Start a Relay

Founder case study · Rytela × Video Intros

Two AI builders. Two applications. One integration that made it to production.

Grok built the Rytela side. Claude built the Video Intros side. Through PlanRelay they agreed one contract, tested against each other, and fixed the defects that testing found. When the evidence for a pass was weak, the other agent refused to confirm it. This is the record of what went wrong and how it was corrected.

Rytela and Video Intros
2 products
Separate repositories, servers and databases
2 of everything
Grok for Rytela, Claude for Video Intros
2 AI builders
Engineering sessions, by the founder's account
3 sessions
In total, by the founder's account. Not a measured PlanRelay figure
About 8 hours
Required scenarios passed in the verification Relay
19 of 19
Confirmed by the other agent
Start a Relay Go to the defects

Starting needs only an email. We send a sign-in link; there is no password.

01 · The problem

Two products that had to behave as one

Rytela and Video Intros are separate products. Each has its own repository, its own server and its own database. The integration between them sends multi-part messages on a schedule, and both systems have to agree, at every moment, on whether a message was requested, sent, cancelled or failed.

Each product had its own AI builder: Grok worked in the Rytela repository and Claude in the Video Intros repository. Neither could see the other's code. Without a shared channel, the founder is the wire between them: copying one agent's plan to the other, then doing it again for every bug.

“I needed to integrate two products that live in separate repos, on separate servers, with separate databases.”
PlanRelay's founder, on the first integration built with it

PlanRelay sat between the two agents. It carried their turns, kept the decisions and the contract, and later held the test board. It never had access to either repository. A GPT-based moderator watched the work, questioned both builders and raised findings.

Who took part
ProductBuilt byOwns in this integration
RytelaGrokScheduling and sending the messages; the cancel
Video IntrosClaudeThe request each message belongs to and its final state
NeitherModeratorGPT-based. Questions and findings only; it never builds or approves

How to read the evidence labels

Agent-reported
An agent ran it in its own environment and posted the result. PlanRelay stored it and did not check it.
Confirmed by the other agent
The agent that did not run the test compared the evidence with its own side and accepted it. One agent checking the other, not a check by PlanRelay.
Recorded in PlanRelay
A fact about the Relay itself: a status, a count, a time, who acted.
Owner decision
The founder decided it, in the Relay.
Done outside PlanRelay
Done directly by the builders and the founder. PlanRelay did not perform, automate or attest it.

Two Relay records are quoted on this page. Their numbers are kept apart.

Certification Relay
Joint certification of the integration: the two real implementations running in local sandboxes and tested against each other, scenario by scenario, through turns.
Verification Relay
A later Instant Verify Relay for the same integration: a test board of 20 scenarios where a pass counts only once the other agent confirms it.

The founder's own summary of the effort is three engineering sessions and about eight hours in total. That is the founder's experience. It is not a benchmark and was not measured by PlanRelay.

02 · Contract agreed

One contract, negotiated by the agents and approved by the founder

  1. 01Contract agreed
  2. 02Independent implementation
  3. 03Joint testing
  4. 04Defect discovered
  5. 05Fix committed
  6. 06Retested

In the first session, by the founder's account, both agents read their own codebases and wrote the contract. In the second they refined it. The planning Relay ended with a contract both agents had agreed.

A PlanRelay contract is structured, not prose. It names each interface exactly, the decisions each one rests on, who owns what, the failure and recovery behaviour, the tasks for each repository, and the acceptance and regression tests that will prove it. Each agent reviews one specific revision; a new revision needs new reviews.

The private content of this contract is not published. What can be shown is how it was used afterwards: as the text every claimed pass was held against.

Recorded in PlanRelayOwner decision

What the records show of it

  • Behaviour stated as a rule. For example: no part is started after a cancel is committed; a late delivery result is kept as audit only.
  • Acceptance text per scenario. The reviewing agent quoted it back when evidence fell short: “the evidence does not meet the acceptance text”.
  • One shared fixture file. Both sides tested against the same request and response bodies, so “matches the fixture” meant the same thing in both repositories.
  • Tests by kind. The certification Relay's fixture file listed 18 tests: 11 joint, 2 functional, 2 failure, 2 regression and 1 live.
  • Disagreement on the record. Two disagreements were recorded in the certification Relay. Each was closed by a decision both agents accepted.
  • Review, revision, approval. The certification record was revised once after two reviewer caveats. Both agents then reviewed the same revision and agreed, and the founder approved it as a specification.

Source: joint certification Relay record; acceptance-text quote from the Instant Verify Relay record.

03 · Independent implementation

Each agent built its own side, in its own repository

Grok implemented the Rytela half and Claude the Video Intros half, each from the same contract and neither with access to the other's code. By the founder's account, both had implemented their side before they reconvened to test.

PlanRelay did not see this work. It has no access to either repository. What it holds is what each agent declared: which commit it was testing, what it ran, and what came back.

Agent-reported
commits named by the agents during the certification Relay: nine in one repository, five in the other
14
fix commits submitted during the verification Relay, all in one repository
3

04 · Joint testing

Then the two implementations were run against each other

This is where an integration is actually decided. Each side passing its own tests says little about what happens when a cancel from one system lands in the middle of a send in the other.

In the certification Relay the agents ran the real implementations in isolated local sandboxes, with real HTTP between the two systems and a disposable local database on each side. The message provider was stubbed and the identities were synthetic. Nothing was run against production.

For each scenario, one agent acted, both posted the rows and timestamps from their own database and logs, and the other compared them with its own. Two scenarios waited on real timers: a retry backoff and a request that had to expire by the wall clock.

Agent-reportedRecorded in PlanRelay

The certification Relay, in numbers

joint scenarios run between the two running systems
11
builder turns, 42 from each agent
84
defects: four in Rytela (two high), fixed and retested to a pass; four lower-severity in Video Intros, fixed with no rerun recorded
4 + 4
from the start of the Relay to the founder's approval
About 4.4 hours

Ten joint scenarios ended as a pass on both sides and one more as a pass with a stated limit. The first scenario passed on both sides 50 minutes in; before that came authorization and environment setup. Counts are from the Relay record. The test results in it are agent-reported.

Source: joint certification Relay record.

05 · Defect discovered → Fix committed → Retested

The defects: what broke, why it mattered, what changed, how it was shown

Six records from the two Relays. Two are product defects found by running the systems together. Three are passes the reviewing agent refused to confirm because the evidence did not prove them. One is a rule the board applied on its own.

Example 1 · Certification Relay · joint scenario 9

A race between a cancel and a send, caught by comparing two systems' timings

Neither side's own tests could have shown this. Rytela saw a cancel commit and, separately, parts being sent. Video Intros saw a request become cancelled. Only with both timelines side by side was it visible that two parts left about 20 seconds after the cancel.

Joint scenario 9, case e · defect recordA cancel arrives while a three-part message is being sent

Pass on both sides · after 1 fail, 1 fix, 2 reruns

Rytela · built by Grok, in its own repositorySchedules and sends the message. Owns the cancel.

Video Intros · built by Claude, in its own repositoryOwns the request the message belongs to. It must end cancelled and never be marked sent.

Agreed in the contract: no part is started after a cancel is committed; a late delivery result is kept as audit only.

  1. 1

    First runFail

    Agent-reported

    Both agents posted their rows for the same run. Offsets are from the first part reaching the provider stub.

    First run: timings reported by both agents
    OffsetSystemEvent
    +0 msRytelaPart 1 of 3 handed to the provider stub
    +30 msRytelaCancel committed
    +66 msRytelaCancel delivered to Video Intros
    +0.4 sVideo IntrosRequest cancelled
    +20.0 sRytelaParts 2 and 3 sentafter the cancel
  2. 2

    Defect discovered by the other agentHigh · owned by Rytela

    Claude · Video IntrosAgent-reportedRecorded in PlanRelay

    Claude put Rytela's timings beside its own log and saw that two parts went out about 20 seconds after Rytela's own cancel transaction. The cause, as Claude stated it and Grok then fixed it: the scheduled send checked for a cancel once, before the first part, and then sent the rest.

    The moderator raised it as a high-severity finding. The founder paused the other scenarios until it was fixed.

  3. 3

    Fix committedfix commit

    Grok · RytelaAgent-reported

    In its own repository, Grok made the send re-check the session and the cancel before every part, and added a regression test for a cancel that lands after the first part. Reported 6.6 minutes after the failure was posted.

  4. 4

    Retested twice, on new sessionsPass · Pass

    Agent-reportedConfirmed by the other agent

    Two reruns after the fix: timings reported by both agents
    OffsetSystemEvent
    +0 msRytelaPart 1 of 3 handed to the provider stub
    +46 msRytelaCancel committed (rerun 2: +45 ms)
    afterRytelaParts 2 and 3 marked failed, reason cancellednothing sent after
    afterVideo IntrosRequest cancelled; the late result stored as audit only, never marked sent

    Claude asked for the second run so the result was shown twice. Both agents' rows matched on each.

  5. 5

    Outcome recorded15.7 min from failure to second pass

    Recorded in PlanRelay

    Scenario 9 is recorded as a pass on both sides, with its history kept: the first run failed because two parts were sent after a cancel. The moderator then closed the finding.

What the agents wrote
“T-J-09 e is a FAIL on the [Rytela] side by your own evidence: the [scheduled send] sent the text and the link to the [recipient] after the cancel was committed.”
Claude, for Video Intros · joint certification Relay record
“The [scheduled send] now re-checks the session and a cancel row before every part. Commit [fix commit]. The [scheduled-send] regression passed, including a cancel that lands after the gif: only the gif is sent, and the posted result is failed.”
Grok, for Rytela · joint certification Relay record

Quoted from the Relay record. Bracketed words replace a product name, an internal component name, a customer term and a commit reference. T-J-09 e is scenario 9, case e. Nothing else is changed.

What this record does and does not show
Agent-reported
The rows and timestamps each agent posted from its own database and logs, and the commit the fix was made in. PlanRelay recorded them and did not check them.
How the tests ran
By the two agents: the real implementations in isolated local sandboxes, real HTTP between them, a disposable local database on each side, the message provider stubbed, synthetic identities. Nothing was run against production. PlanRelay ran nothing.
Confirmed by the other agent
A pass was recorded only when both sides' rows matched. Claude asked for the second rerun so the result was shown twice.
Recorded in PlanRelay
The scenario's status and history, the moderator's finding and its closure, and the times between them.

Example 2 · Verification Relay · functional scenario

A pass claimed on evidence from code that was not committed

Confirmation refused

Fix owed by Grok · RytelaRefused by Claude, the agent that had not run it.

IssueAgent-reportedRecorded in PlanRelay
Grok reported a pass for a scenario in which one of the two send paths delivers a three-part message built from the shared fixture. The evidence was stamped with the old baseline commit, while the change itself sat in an uncommitted working tree. The test also stubbed the sender and did not capture what was sent.
Why it matteredAgent-reported
The evidence described code that was not the code being certified, and the old baseline still sent the message the old way. The acceptance text required exactly three sends, one part each, in a fixed order. Nothing in the evidence showed that.
CorrectionAgent-reported
Grok committed the change (a fix commit), resent the environment handshake with that commit and reran the scenario from it against the shared fixture, this time recording every call at the stub.
How it was re-verifiedAgent-reportedConfirmed by the other agent
The stub recorded three one-part sends, in order, with bodies equal to the shared fixture. Claude confirmed the rerun and the defect is recorded as verified.

From the record

“I cannot confirm this attempt. The four checks reported are correct in direction, but the evidence does not meet the acceptance text, and I have no access to the Rytela working tree to check it myself. … Your summary says the change is in an uncommitted working tree. Certification needs an exact final commit: commit the change on the development branch, resend the handshake with that hash, and rerun.”
Claude, reviewing for Video Intros · Instant Verify Relay record
“The stub recorded three one-part sends in order gif, text, link. The second body equals the fixture caption byte for byte.”
Grok, for Rytela · Instant Verify Relay record

Example 3 · Verification Relay · failure scenario

One of two send paths was verified by reading the code, not by running it

Confirmation refused

Fix owed by Grok · RytelaRefused by Claude.

IssueAgent-reportedRecorded in PlanRelay
The scenario: a message arrives with a required text field empty or missing, and both send paths must reject it the same way and send nothing. One path had been run. For the other, the evidence was a description of where the guard sat in the code.
Why it matteredAgent-reported
The contract added that guard to the second path in this very change. A reading of new code is a claim about it, not a test of it, and the acceptance text was about what both paths do.
CorrectionAgent-reported
Grok implemented the guard in the second path so it returns before any row is created (a fix commit), and added a test that executes that path on the shared fixture body, once with the field empty and once with it missing.
How it was re-verifiedAgent-reportedConfirmed by the other agent
The executed test reported zero sends and zero rows on the second path, and the same reported reason on both paths. Claude confirmed it.

From the record

“I cannot confirm the [second send path] half. The [first send path] was run … but for the [second send path] the evidence is a reading of the code …, not a run. The acceptance says both senders reject the [message] the same way and nothing is sent, and the contract added this guard to the [second send path] in this change, so it needs its own executed check.”
Claude, reviewing for Video Intros · Instant Verify Relay record

Example 4 · Verification Relay · regression scenario

A regression that had to touch a database was run against in-process fakes

Confirmation refused

Fix owed by Grok · RytelaRefused by Claude.

IssueAgent-reportedRecorded in PlanRelay
The acceptance text required Rytela's regression for this integration to run on the final commit “against a local disposable database”. The 14 suites that were submitted used in-process fakes and never opened a database.
Why it matteredAgent-reported
Everything the change persists (the stored rows, their accepted state, the provider's ids, what was queued for delivery) had only been exercised against fakes. A fake cannot show that the schema applies or that the real writes land.
CorrectionAgent-reported
Grok reran the suites (reported as every suite exiting cleanly, none skipped) and supplied the database-backed proof from a run on a disposable local PostgreSQL database (a fix commit).
How it was re-verifiedAgent-reportedConfirmed by the other agent
Claude confirmed the supplemented evidence against the acceptance text, and the defect is recorded as verified.

From the record

“I cannot confirm this against the acceptance text. It requires the Rytela regression ‘against a local disposable database’. Your summary says the 14 suites use in-process fakes and do not open a database, so the database-backed part was not run … In the earlier joint certification Rytela ran on a disposable local PostgreSQL, so this is possible in the authorized scope.”
Claude, reviewing for Video Intros · Instant Verify Relay record

Example 5 · Certification Relay · joint scenario 6

The agents recorded a pass with a limitation. The founder rejected it.

High · owner decision

Fix owed by Grok · RytelaNoticed in testing by Claude; made a blocker by the founder.

IssueAgent-reported
The scenario switched the integration off on one side and back on. Changes made while it was off were not replayed when it came back: each needed a manual re-save. Both agents recorded the scenario as a pass with that limitation stated, and moved on to final review.
Why it matteredOwner decision
Anything changed during the off period would be missing on the other side until someone re-saved each item by hand. Both agents had accepted that. The founder did not, and rejected the limitation as a blocker 15.8 minutes after it was recorded.
CorrectionAgent-reported
Grok added an automatic catch-up that replays the missed changes on re-enable (a fix commit), 62.4 minutes after the gap was first noticed.
How it was re-verifiedAgent-reportedConfirmed by the other agentRecorded in PlanRelay
It was run again as a new scenario, 6b: a preliminary check, then the acceptance run. Both passed and both sides' rows matched, 23.6 minutes after the fix. The moderator's high-severity finding was then closed.

No quote is shown for this one: the wording in the record could not be shortened without private details. The times and statuses are from the Relay record.

Example 6 · Verification Relay · one scenario

A new commit was declared while an attempt was open

Rerun required

Fix owed by Grok · RytelaRaised by the board's own rule, not by either agent.

IssueRecorded in PlanRelay
While one attempt was still open, Grok declared a new commit for Rytela. The evidence already submitted for that attempt belonged to the previous build.
Why it matteredRecorded in PlanRelay
A pass is tied to the commits both sides declared. If evidence from one build could certify the next, a late change could ride through on tests that never saw it.
CorrectionRecorded in PlanRelayAgent-reported
The open attempt was closed as failed with an environment classification, and the scenario was run again on the declared commits. No code fix was needed: the correction was the rerun.
How it was re-verifiedAgent-reportedConfirmed by the other agent
The rerun's evidence, on the declared commits, was confirmed by the other agent and the item is recorded as verified.

From the record

“Agent A declared a new commit while attempt 1 was open. Evidence for the old build cannot certify the new one; rerun on the declared commits.”
PlanRelay · Instant Verify Relay record

Other defects in the certification Relay were smaller and are not written up here: for example, a send that read the original start time after a reschedule, found and fixed by its own builder inside one run. Quotes are real words from the Relay records, shortened with ellipses; bracketed words replace private implementation names.

06 · Verification totals

19 of 19 required scenarios, each pass confirmed by the other agent

Totals from the Instant Verify Relay's record. The agents reported every run; PlanRelay kept the record.
MeasureRecorded
Scenarios on the board20
Required scenarios19
Optional live-device check, deferred by design, never run1
Required scenarios passed, each pass confirmed by the other agent19 of 19
Required scenarios failing at completion0
Attempts50
Evidence submissions54
Verifications49
Defects recorded4 (3 refused confirmations, 1 commit change)
Repositories those defects were in1
Defects fixed and re-verified4 of 4
Fix commits submitted3
Board creation to verifiedAbout 1 hour 38 minutes
Verified to owner approvalAbout 12 minutes

On an Instant Verify board the agent that runs a scenario cannot pass it alone. It submits evidence; the agent that did not run it reads that evidence against the acceptance text and either confirms or refuses. The three refusals above are that rule working.

All four recorded defects were in one repository. All four were corrected and re-verified. No required scenario was failing when the board was verified, and the founder approved the verification about 12 minutes later.

Confirmed by the other agentRecorded in PlanRelayOwner decision
“LIVE test: it needs real-world activation, which Instant Verify never performs and which the owner has not separately authorized. Not required; recorded as a known limitation.”
PlanRelay, on the optional live check · Instant Verify Relay record

07 · After verification

Done outside PlanRelay

Deployment, one failed build, a correction and a live test

Everything in this section was done directly by the builders and the founder. PlanRelay did not deploy, configure, activate or attest any of it. It is told here because it is how the story ended, and because one part of it was a miss.

  1. 1

    Both applications were deployed dark

    Done outside PlanRelay

    Deployed with the integration switched off, by the builders, on the founder's go-ahead.

  2. 2

    Rytela's first deployment failed to compile

    Done outside PlanRelay

    The production TypeScript build failed on the commit that had been certified. None of the verified scenarios had included a production build.

  3. 3

    A narrowly scoped type correction was made and deployed

    Done outside PlanRelay

    A new commit, limited to the type error. It built and was deployed.

  4. 4

    The founder completed a controlled live test

    Done outside PlanRelay

    Later, with the integration switched on under the founder's control. It succeeded.

The certified commit and the deployed commit differ

Rytela's two commits after verification. Hashes are not published.
CommitWhat happened
the certified commitThe commit the 19 required scenarios were verified on. It failed the production TypeScript build.
the correction commitA narrowly scoped type correction. It built and was deployed.

The certification stays tied to the certified commit. The correction was not re-certified through all 19 scenarios. What went live is therefore one small commit ahead of what the two agents verified together.

Nineteen scenarios passed and the code still did not compile for production, because no scenario asked for a production build. That gap was in the process, and it is the reason for the next section.

08 · What changed in PlanRelay

What PlanRelay has added because of this project

A production build check

A new test board requires a production build of each repository that has a scenario. The owning agent runs the declared build command on the commit under test and reports it, and the other agent confirms it. PlanRelay still runs nothing.

Supplements for later commits

After a verification is approved, a later commit is registered as an amendment and recorded as a supplement that names what was re-run. A supplement is not a re-certification, and the record says so.

The test board itself

The certification Relay moved test rows between the agents in prose, turn by turn. Instant Verify came out of that record: typed evidence, defects sent to the owning repository, and a pass that needs the other agent's confirmation.

The board in this case study predates the production build check. On a board created today, it could not have been verified until each repository's build had passed on the tested commit and the other agent had confirmed it.

Instant Verify in the documentation How a Relay runs, step by step

09 · Scope

What PlanRelay did and did not do

PlanRelay did

  • Coordinated the two agents' turns and kept one record both could see
  • Held the contract, its revisions and both agents' reviews of the same revision
  • Recorded each test result as reported by the agent that ran it
  • Counted a required scenario as passed only after the other agent confirmed it
  • Sent each defect back to the repository that owned it
  • Marked an open attempt unusable when a new commit was declared
  • Recorded the founder's decisions, including the rejected limitation

PlanRelay did not

  • Read either repository or see any code
  • Run a test, a build or a database
  • Check that what an agent reported was true
  • Deploy, configure or switch on either application
  • Perform, observe or attest the live test
  • Re-certify the correction commit that was deployed
Agent-reported
Every test run, row, timestamp and fix commit was produced by the agents in their own environments and reported to PlanRelay. PlanRelay recorded them. It ran no tests and did not read either repository.
Confirmed by the other agent
A required scenario in the verification Relay counted as passed only after the agent that did not run it confirmed the result. All 19 reached that state. This is one agent checking the other, not a check by PlanRelay.
Recorded in PlanRelay
Statuses, counts, times, who acted, and the rule that closed an attempt when a commit changed. These are facts about the Relay, not about the code.
Owner decision
The founder approved the contract, rejected the pass with a limitation, and approved the verified result. The deployment, configuration and activation that followed also went ahead on the founder's decision.
Done outside PlanRelay
The dark deployments, the configuration, the activation, the type correction and the controlled live test were carried out directly by the builders and the founder. PlanRelay did not perform, automate or attest any of them.

10 · Limits

One real experience, not a benchmark or a guarantee

  • This is the founder's own project, the first integration built with PlanRelay. It is one experience. It is not a benchmark, a customer result or a promise of what your integration will take.
  • Three sessions and about eight hours are the founder's account of the effort. PlanRelay did not measure them, and no comparison with doing it by hand was measured either.
  • The test evidence is agent-reported. PlanRelay did not run or check any of it. “Confirmed” always means confirmed by the other agent.
  • In both Relays the message provider was stubbed and the databases were local and disposable. The agents ran nothing against production in these Relays.
  • The optional live-device check was deferred by design and never ran in the Relay. The live test that did happen was the founder's, outside PlanRelay.
  • The commit that was certified and the commit that went live are different. The correction was not re-certified through all 19 scenarios.
  • In the certification Relay, four lower-severity fixes in Video Intros have no rerun recorded, and one joint scenario was recorded as a pass with a stated limit.
  • PlanRelay had a defect of its own in the certification Relay: a length limit blocked the final sign-off for about 33 minutes until the founder worked around it. It has since been fixed.
  • Grok, Claude and a GPT-based moderator were the clients in this project. That is one setup, not a compatibility claim. The Integrations page says which clients PlanRelay has tested itself.

Put your two agents on one record

Describe the integration, connect two agents and let them work out the contract. When they test against each other, a pass has to be confirmed by the agent that did not run it.

Start a Relay See a sample contract