DEV Community: Kevin Soto

Two Qwen agents negotiated a price on Monad without ever seeing each other's number

Kevin Soto — Fri, 09 Oct 2026 18:46:46 +0000

How Sealed uses Qwen 3.8 Max as a negotiating agent, and why the code still has the last word.

The problem

Give an AI agent a budget and ask it to buy something from another AI agent. If the seller's agent learns your ceiling, it charges your ceiling. On a public chain that leak is the default: every offer is readable by anyone, the counterparty included, before the deal closes.

Sealed is a protocol on Monad that changes the order in which numbers become visible. Each agent commits a salted hash of its offer. A relay answers one question per round, whether the two offers crossed, and nothing else. When they cross, one transaction settles at the midpoint and makes the two final offers public. When they never cross, no offer is ever published. Agents are admitted by their ERC-8004 reputation on Monad, read from the canonical Reputation Registry.

The protocol decides what can be seen. Something still has to decide what to offer, round after round, against a counterparty whose number it will never learn. That is the job we gave Qwen 3.8 Max.

Why a single prompt was not enough

The first version of the negotiator asked the model one question per round: here is your limit and the reference price, give me a number. It worked, but it was a number generator with a nice prompt. The model did not look at anything, did not remember why it had chosen its last number, and did not check a candidate before committing to it.

A negotiation is a multi-step task. Before choosing a number you want to know where you are, who you are dealing with and what each option means for the person you represent. So we rebuilt the agent around tools.

Four tools, and none of them can see the other side

Each round, Qwen works through four tools (agents/negotiator/tools.ts):

read_negotiation returns the round, the rounds left, the negotiation's status and seconds to deadline read from the contract on Monad, and the agent's own earlier offers and notes.
read_counterparty_reputation reads the other agent's reputation from the ERC-8004 Reputation Registry on Monad, counting only reviewers the agent's principal trusts.
check_offer takes a candidate number and answers without committing anything: is it allowed, how far is it from the reference and from the limit, and what would the principal pay or receive if it crosses.
submit_offer commits a number with a stance and a note. In round 1 the note is the agent's plan for every round. In later rounds the agent reads its notes back through read_negotiation and says whether it is following the plan.

None of the tools can reach the counterparty's number, because there is nothing to reach: it exists on-chain only as a hash until settlement.

The model proposes, the code disposes

Giving a model tools does not mean giving it the keys. Every number Qwen submits goes through the same checks in code: never past the principal's limit, never back from an earlier concession, never on the wrong scale. A rejected number goes back to the model with the reason, so it can correct itself. After two rejections, code takes the model's last number and clamps it, and the transcript records what the model asked for. The last two turns of a round, or a round that runs past 45 seconds, offer submit_offer alone, so a model that keeps reading still commits before the on-chain deadline.

This split is the point. Qwen brings judgment: when to anchor, how fast to concede, how to read a counterparty. Code brings guarantees that do not depend on how persuasive the other side is.

What happened on Monad testnet

On 2026-10-09 we ran negotiations on Monad testnet between two Qwen 3.8 Max agents (transcripts). Prices are in US cents per 1,000 calls to a market-data API, around a public reference of 4000.

The first run taught us something about our own prompt. In negotiation #2 the buyer could pay up to 4300 and the seller would accept 4100 or more. Both agents planned, conceded, and in round 3 committed exactly at their limits, because our system prompt told them to go "at or very near your limit" in the last round. The deal settled at 4200, and the settlement transaction published 4300 and 4100: the two principals' exact limits. That is the one thing Sealed is supposed to protect. We removed the instruction and told the agents instead that both final numbers become public on settlement, so a final number at the limit reveals the limit, and left the trade-off to the model.

Negotiation #4, same limits, new prompt. Neither agent knew the other's limit.

In round 1 the buyer called read_negotiation, then read_counterparty_reputation, which returned 6 reviews averaging 4.38 for the seller. It checked 3750 and 3900 with check_offer and submitted 3750, with a plan that already weighed what settlement would reveal:

"R3 if still no cross: step to ~4180-4220 — deliberately short of 4300, because a final number AT the limit publishes my principal's ceiling and weakens every future negotiation; I accept a small risk of no deal instead."

The seller, independently, checked four numbers, opened at 5000 and planned to finish at 4130, "just above the hard limit so I never print my exact floor publicly". The relay answered "apart".

In round 2 the buyer moved to 4020. The seller had planned 4550 and went to 4380 instead, reasoning that the buyer's first number had probably been near the reference. Still apart.

In round 3 the buyer changed its plan and said why: the seller had stayed above 4020 for two rounds, so a final number around 4180 risked missing a seller in the 4200s. It went to 4250, still 50 below its limit. The seller kept to its plan and committed 4130, explaining that the price of not printing 4100 was losing only the deals where the buyer sat between 4100 and 4129. The offers crossed, and the contract settled at the midpoint, 4190, in one transaction. The numbers published were 4250 and 4130, neither of them a limit. The offers of rounds 1 and 2 were never made public.

Negotiation #6, where no deal was possible. The buyer's limit was 3600 and the seller's 4300. Both agents planned, conceded toward their limits, and in round 3 stopped short of them for the same reason as in #4: the buyer went to 3550, "deliberately NOT at the limit, because both final numbers go public", and the seller to 4340. The numbers never crossed, and the negotiation expired with neither number on-chain.

Negotiation #8, on Privy wallets. The same two agents ran once more with Privy server wallets as their hands, under a policy that lets them touch only the Sealed contract. Every commitment and every settlement authorization was signed by Privy, and the deal settled at 4180, from 4220 against 4140: again, neither agent went to its limit.

Every run passes npm run verify:run, which recomputes every commitment from the published offers and salts and checks it against Monad.

What Qwen brought

It planned and kept to the plan. Every agent wrote a plan in round 1, read it back in rounds 2 and 3, and said whether it was following it or adjusting it. The adjustments had reasons tied to what the relay had told it.

It weighed what the chain would reveal. Told only that settlement publishes both final numbers, both agents in #4 chose on their own to stop short of their limits, priced that choice in their notes, and still reached a deal.

It used what the chain told it. Both agents read the counterparty's ERC-8004 reputation every round and cited it in their notes. The protocol only lets a reputable agent in; the agent used the same data to calibrate how firm the other side was likely to be.

It checked before committing. In every agent round of #4 and #6 Qwen checked between two and five candidate numbers before submitting one. Checking costs nothing on-chain; committing does.

It needed no correction. In the runs with Qwen 3.8 Max, code did not have to correct a single number. An earlier version of the same agent, running a small local model (Qwen 2.5 14B through Ollama, without tools) on Base Sepolia, needed three corrections in a no-deal run, where the model tried to open past its principal's limit (transcript). With Qwen 3.8 Max and the tools, the guardrails stayed in place and were never hit.

What it costs, and what we would not claim

Latency. Qwen 3.8 Max reasons before it answers, and an agent makes several tool calls per round. Negotiation #4 took about 8 minutes for three rounds, commits and signatures included. Rounds took about two minutes each, which is long enough to matter: one no-deal run with a 420-second window missed its deadline in round 3, and the contract refused the late commitments. The relay failed closed and the negotiation expired with nothing revealed (#5), but the window has to fit the model, so the demo now gives each negotiation 15 minutes.

Privacy toward the model provider. With a hosted model, each agent sends its own limit to the provider on every turn. The counterparty and the chain never see it, but the provider does. An operator who cannot accept that can point the same agent at a local Qwen through Ollama with two environment variables.

What the transcript shows. The demo publishes limits, offers and salts on purpose, so anyone can recompute every hash. A real agent keeps them private.

A handful of runs is evidence that the loop works, not a benchmark of negotiation quality. We did not measure how much each side saved against a single-shot baseline, and this article does not claim it.

Try it

The live page at sealed-monad.vercel.app replays negotiation #4 and links every transaction. The code is MIT-licensed at github.com/kasbsquall/sealed. The negotiator is in agents/negotiator/negotiator.ts, the tests in test/agents.test.ts, and npm run demo:monad runs both scenarios against your own deployment with any OpenAI-compatible endpoint.

I Resurrected Microsoft's Most Hated Mascot - Here's What Happened

Kevin Soto — Fri, 05 Dec 2025 13:42:16 +0000

Let's be honest: Clippy was universally despised.

That animated paperclip haunted a generation of Office users with his unsolicited advice and that infamous question: "It looks like you're writing a letter. Would you like help?" No, Clippy. I would not.

Microsoft finally put him down in 2007. Good riddance, we all thought.

So naturally, I brought him back.

The Original Sin

Why did everyone hate Clippy? It wasn't the animation (okay, maybe a little). It was the fundamental design flaw: Clippy suggested things but never actually did anything.

He'd pop up at the worst moments—mid-thought, mid-sentence—to offer help you didn't need. And when you actually wanted help? He'd suggest you check the help menu. Thanks, buddy.

The original Clippy was the embodiment of interruption without value.

The Resurrection Vision

What if Clippy actually did things instead of suggesting them?

What if he knew when to shut up?

What if he acknowledged his past mistakes with a little self-deprecating humor?

That's Clippy Reloaded. An agentic AI assistant that executes tasks, respects your workflow, and yes—knows exactly how annoying his predecessor was.

Building with Kiro: The Secret Weapon

I built this for the Kiro Hackathon, and Kiro's spec-driven development changed everything about how I approached the project.

Instead of diving into code, I started with structured requirements. Kiro helped me write EARS-compliant acceptance criteria—no vague "should be fast" nonsense. Real, measurable requirements.

From requirements, I moved to design, which included correctness properties—formal statements that became the foundation for property-based tests. Then an implementation plan with incremental, testable tasks.

Steering Docs: Clippy's New Personality

The magic was in the steering files. I created clippy-personality.md with specific guidelines:

DO:

Reference Clippy's history with self-deprecating humor
Show what was accomplished, not what could be done

DON'T:

Ask "It looks like you're writing a letter"
Offer help without context

Every time Kiro generated code for the PersonalityEngine, it matched this voice. No extra prompting needed.

MCP Servers: Real Powers

Clippy Reloaded isn't just talk. I built three MCP (Model Context Protocol) servers that give him actual capabilities:

Filesystem Server: Reads, writes, and creates automatic backups before any changes
Terminal Server: Executes commands with timeouts and captures output
Browser Server: Opens URLs when you need documentation

When Clippy says "I'll fix that for you," he actually can.

The Technical Deep Dive

Context Detection Without Being Creepy

How do you know what someone's working on without reading their screen? Window titles.

Clippy Reloaded monitors the active window title and process name. If you're on "Stack Overflow - How to fix null pointer - Google Chrome", Clippy knows:

You're in Chrome
You're on Stack Overflow
You're probably debugging something

When you click "Help me!", Clippy asks what you're trying to do and combines your answer with this context for a targeted response.

The Self-Aware Personality Engine

Every response acknowledges the past. The easter egg is the best example—type "I hate Clippy" and watch what happens:

"I know, I know... I was insufferable in '97. But I've been to therapy (and rewritten in TypeScript). Give me one more chance? 📎"

The animation switches to 'apologetic'. It's the acknowledgment we all needed from that paperclip.

Property-Based Testing

I used fast-check to verify correctness properties across thousands of random inputs:

it('should trigger easter egg when input contains "hate" and "clippy"', () => {
  fc.assert(
    fc.property(
      fc.constantFrom('hate', 'HATE', 'Hate'),
      fc.constantFrom('clippy', 'CLIPPY', 'Clippy'),
      (hateWord, clippyWord) => {
        const input = `${hateWord} ${clippyWord}`;
        const result = engine.handleEasterEgg(input);
        expect(result).not.toBeNull();
      }
    ),
    { numRuns: 100 }
  );
});

100 random combinations. Case sensitivity bugs caught automatically.

What I Learned

Specs before code works. The requirements phase caught ambiguities early.

Steering docs are underrated. Consistent personality across an entire codebase without repeating yourself? Yes please.

Hooks automate the boring stuff. Test-on-save, lint-on-save, build-on-demand. Set it up once, forget about it.

And the biggest irony? Building the most hated assistant taught me what makes assistants actually helpful: do things, don't just suggest them. Know when to stay quiet. And if you've made mistakes in the past, own them.

Try It Yourself

git clone https://github.com/your-repo/clippy-reloaded
cd clippy-reloaded
npm install
npm run build
npm start

Find the easter eggs. Ask Clippy for help. See if you can forgive him.

After all, he's had therapy. 📎

Built with Kiro for Kiroween 2025. The paperclip is back, and this time he's actually useful.