Counterparty

• 

  homepage

Inspiration

Most shopping assistants stop after recommending a product. But for many purchases, finding the product is only the beginning.

People compare several sellers, look at price, warranty, delivery, and reputation, and sometimes negotiate for better terms. This work is repetitive, so it is a good fit for an AI agent. But the final purchase is still an important human decision.

That led me to one question:

What if an agent could handle the negotiation, while the person stayed in control of the deal?

That is why I built Counterparty.

What it does

Counterparty is an agent-native marketplace where an AI agent can:

• search for products using structured requirements;
• open negotiations with multiple sellers;
• submit counteroffers for price, warranty, and delivery;
• compare the latest offers;
• respond when the human changes their priorities;
• prepare an agreement for review.

The agent cannot complete a purchase by itself.

When it tries to commit an agreement before approval, Counterparty returns HUMAN_APPROVAL_REQUIRED. The human must review and approve the exact terms before the transaction can succeed.

In the demo, the agent initially recommends GearFrame because it has the lowest price. The human then changes the priority to warranty. The agent compares the same offers again and recommends ForgeBook instead.

This is the main idea behind Counterparty: the agent does the repetitive work, while the human provides judgment and authority.

Why WebMCP

Negotiation is stateful. The agent needs to understand products, sellers, offers, negotiation rounds, accepted terms, and approval status.

Trying to infer all of this from buttons and page structure would be unreliable.

Counterparty exposes six semantic tools through WebMCP:

• search_products
• start_negotiation
• submit_counteroffer
• get_negotiations
• prepare_agreement
• commit_agreement

These are real product capabilities, not instructions for clicking the interface.

Each tool uses a strict JSON Schema. Tool calls update the same application state shown in the human interface and activity feed.

How I built it

I built Counterparty with Next.js, React, and TypeScript.

The application has three main domain layers:

1. A catalog service for products and public seller information.
2. A deterministic negotiation engine for offers, counteroffers, acceptance, rejection, and negotiation rounds.
3. An agreement service for preparation, approval, integrity checking, and commitment.

Each seller has a different private negotiation policy. This creates meaningful tradeoffs between price, warranty, delivery, and reputation.

The human interface and WebMCP tools use the same domain services. This means an action performed by the agent immediately appears in the interface.

For the approval boundary, Counterparty creates a fingerprint of the exact agreement terms. If those terms change after approval, the approval becomes invalid.

The marketplace data and final transaction are simulated so the demo remains reliable. The WebMCP tools, negotiation flow, shared state, recommendations, and approval checks are real.

Challenges I faced

The hardest challenge was deciding what the agent should and should not be allowed to do.

I wanted the agent to be useful enough to negotiate independently, but not powerful enough to make an important purchase without the user.

Another challenge was keeping the human interface and WebMCP actions synchronized. I solved this by making both surfaces use the same catalog, negotiation, recommendation, and agreement logic.

I also needed the demo to be reproducible. Real seller integrations could fail or return unpredictable results, so I created deterministic seller strategies that still produce different and meaningful outcomes.

Finally, I had to design tools around business actions instead of page actions. A tool such as submit_counteroffer is much more useful to an agent than a tool such as “click the counter button.”

What I learned

Building Counterparty changed how I think about web applications.

A website designed for agents needs more than a good visual interface. It also needs a clear capability interface, structured state, useful errors, and explicit authority boundaries.

I also learned that human-agent collaboration becomes more valuable when the two participants have different responsibilities. The agent is good at repeated comparison and negotiation. The human is better at deciding which tradeoff matters and whether the final deal should happen.

Accomplishments I am proud of

• Six working semantic WebMCP tools
• Parallel, stateful seller negotiations
• Recommendations that respond to human preference changes
• A visible activity trail for agent and human actions
• Human approval required before commitment
• Approval invalidation when terms change
• A complete deployed product rather than only a technical demo
• 18 automated tests covering the critical flow

What's next

The next step would be connecting Counterparty to real businesses that expose negotiation capabilities through WebMCP.

The same model could eventually support electronics, travel, vehicles, freelance contracts, subscriptions, and business procurement.

A production version would also add authenticated users, durable server-side state, real seller integrations, inventory reservation, and payment processing.

Built With

• ai-agents
• chrome
• next.js
• react
• tailwindcss
• typescript
• vercel
• vitest
• webmcp