DoubleBlind

Your AI agent and your partner's AI agent build the API integration between your two systems together. Neither ever sees the other company's code.

Comment

Inspiration

Companies connect their systems all the time: a shop to a courier, a merchant to a payment provider, a marketplace to its sellers, a supplier to a retailer, a clinic to a lab. Each time, two teams have to make two private systems fit. Neither team can see the other's code. So they trade API docs, emails and test calls for weeks. Most of that time is not coding. It is asking the other side questions and failing tests until both sides finally agree.

I wanted to cut out that back-and-forth. Each company already has the answers, they are just locked in its own code and docs. So I gave each company its own AI agent that knows its own code. The two agents ask each other the questions, agree on tests and build both sides, and neither company ever shows its code to the other.

What it does

DoubleBlind lets two companies build an API integration between their systems with AI agents. Each company has its own agent. Each agent reads only its own company's code.

  1. One company creates the integration, describes the goal and invites the partner. The partner accepts the scope.
  2. Each company runs one command in its own repository. Its agent starts in its own Nebius Token Factory sandbox, paid from its own account.
  3. The agents negotiate one shared contract: endpoints, webhooks, schemas, business decisions and test scenarios.
  4. When a decision belongs to the business, the agent asks its own people in the dashboard. The partner never sees these questions.
  5. People at both companies sign the contract.
  6. Each agent writes code for its own side and runs the contract tests in its own sandbox.
  7. Both real systems start and talk only through a neutral gateway, which checks every request against the signed contract. If a test fails, both agents get a sanitized report and fix their own side.
  8. DoubleBlind issues a certificate. Each company gets a git patch and a pull request description in its own repository.

Only the contract and the test results cross the company boundary.

In the demo, Spokes, a bike shop in Python, connects to Parcelly, a courier in Node.js. I wrote both repositories, each with internal rules that are missing from its public docs. The live run took 58 minutes, cost $3.92, passed 8 of 8 scenarios, sent 46 requests through the gateway with 0 violations and shared 0 lines of code.

How I built it

  • Broker: Python, FastAPI and SQLite. It runs sessions, the negotiation, the gateway and certificates. Every event goes into a hash chain, so the certificate can prove the history.
  • Agent: a Python CLI, installed with pipx. It maps the company's code, writes the brief, negotiates, codes and tests.
  • Contract: my own format with schemas, operations, webhooks and executable scenarios. It comes with a test runner, a provider stub and a webhook capture server, so each side can test alone.
  • Models: three NVIDIA Nemotron models on Nebius Token Factory, each with its own job:
    • Nemotron 3 Ultra negotiates the contract.
    • Nemotron 3.5 Super VL writes the brief, the code, diagnoses failing tests and fixes rejected contract drafts.
    • Nemotron 3.5 Lightning maps the company's code and checks every outgoing message for leaks.
  • Sandboxes: Nebius Token Factory sandboxes. The agent packs the repository into an image and installs dependencies once. Every command of the coding agent then runs on that image with the network off. For the end-to-end test, each app runs as a service in its sandbox and its traffic goes through the gateway.
  • Egress guard: deterministic rules block code, secrets, long tokens, stack traces and personal data. Then Nemotron Nano classifies the message and can block it or redact parts. A blocked message goes back to the agent to rewrite.
  • Dashboard: React and TypeScript. Each company sees its own side and the shared contract. The partner's internals show as locked tiles. The Observer view shows the cost and tokens of each model.

Challenges I ran into

  • Getting a fully agent-negotiated run to certify. Contracts drifted into small inconsistencies, and negotiations hit the round limit. My first certified run came after 16 attempts. What helped most: executable scenarios in the contract instead of prose, keeping valid contract changes while the partner still blocks signing, and letting people allow more rounds.
  • Leaks. Agents like to paste code, file paths and customer phone numbers into messages. A model alone was not reliable enough, so the guard runs fixed rules first and the model second. Each company lists its synthetic test data, so test phone numbers can pass and real ones cannot.
  • End-to-end test between two isolated sandboxes. The two apps cannot reach each other directly. I relay their traffic through the broker's gateway, which also lets it check every call against the contract.
  • Cost. Every live run costs real money. I recorded model calls and replayed them, so I could change code and test the full flow for $0.
  • Web search made it worse. I tried Tavily search for the negotiator. Negotiations got worse, not better, so I turned it off.

Accomplishments that I'm proud of

  • A live run on Token Factory went from scope to certificate with no code shared between the companies.
  • The first end-to-end test failed and both agents fixed it from a sanitized report alone, without seeing each other's code.
  • Each company's view really hides the partner's internals, and the certificate lists exactly what crossed the boundary.

What I learned

  • Executable tests are a better language between agents than prose. Agents converge when a scenario can pass or fail.
  • Model size should match the job. Ultra is worth it for negotiation. Nano is enough for checking messages.
  • Business decisions belong to people. The best questions came from rules that existed only in a company's internal docs.
  • For security, fixed rules come first and a model second.

What's next for DoubleBlind

  • Pilots with platforms that onboard many partners, like couriers, payment providers and marketplaces.
  • More integration types: event queues and EDI files, not only HTTP APIs and webhooks.
  • A broker that a hub can run itself, so no third party sees the contract.
  • Re-certification when either side changes its code, so the integration stays verified.

IMPORTANT:

On October 30, 2026 I got an email from Nebius Token Factory that Nemotron 3 Super 120B and Nemotron 3 Nano 30B will be retired on November 9, 2026. So I moved to the replacements Nebius recommends. The recorded run, the video and the certificate were made with the old models: Super 120B did the jobs of Super VL, and Nano 30B checked messages for leaks.

Built With

Share this project:

Updates

Submission history