Speak for Me

AI-assisted scope-change negotiation for customers, providers, and finance—with private constraints and versioned human approvals.

Comment

Watch the 2:57 demo · Open the live product

Inspiration

When a software project's budget changes after approval, customers, providers, and finance need to find new terms—and know which approvals still count.

The customer knows which features matter, the provider knows what can be delivered, and finance knows what can be spent. Speak for Me helps them find a workable agreement while controlling what each party shares and keeping the final commitment in human hands.

What it does

Each participant confirms a structured private brief and chooses which fields to share. The provider confirms catalog prices and lead times. Agents recommend supported options; deterministic code checks scope, budget, dates, and source revisions.

Our demonstration follows one concrete change:

  1. A proposal fits: the cap is $5,000, $4,000 is already committed, and a $900 package includes SSO login, Audit log export, and an optional Usage dashboard. Customer and Provider approve.
  2. The budget changes: Finance lowers the cap to $4,800. The old approvals stop applying. An $800 alternative retains the required features and defers the dashboard.
  3. People decide again: in the measured backend run, agents requested human input. An explicit Customer choice selected the alternative, then fresh approvals for all three roles triggered one recorded outcome: one change order, one budget commitment, and two delivery tasks.

Selecting an option is not approving it. The final valid approval records the outcome atomically; no money moves and no binding contract is signed.

When no option fits, Finance can address the budget or end without agreement. Completed rooms preserve their history; later changes start a linked follow-up room.

How it was built

  • Claude: separate participant contexts for proposal recommendations and escalation to human decisions.
  • TypeScript engine: deterministic rules, candidate construction, privacy projections, and exact approval contracts.
  • Convex: authorized data access, live room state, scheduling, and transactional execution on the final valid vote.
  • Clerk with Google sign-in: identity; backend membership and role checks determine room access.
  • React: the decision inbox, private briefs, proposals, human requests, results, and timeline. Next.js and a thin Vite hosting adapter share the same components and Convex API.

The deployed product uses a real Convex backend.

Challenges

Privacy required more than hiding a budget panel. Data is projected before it reaches another participant's browser or agent. Provider must not receive Finance's cap, commitments, headroom, or private budget-derived explanations. This controls direct disclosure; it does not establish that negotiation outcomes reveal no indirect information.

Approval had to remain correct when constraints changed or requests were repeated. Each decision binds exact terms and a constraint version. The final valid vote must execute once.

Agents also did not always agree. We preserve the actual human-input stop and make recovery explicit instead of presenting it as autonomous success.

Accomplishments and evidence

  • Stale approvals rejected: seven real Claude calls produced the $900 proposal and $800 alternative; changing the budget invalidated old approvals, and a stale approval attempt was rejected.
  • One recorded outcome: explicit human recovery produced one execution, one ledger commitment, one change order, and two tasks. The deployed probe passed duplicate-final-approval and scoped privacy checks.
  • Safe no-agreement outcome: a separate $4,700 scenario ended after Finance's explicit choice, before a first model attempt and without a new commitment.
  • Real browser access: one account completed Google sign-in, loaded the inbox, created a Provider room, and saved/reloaded its private brief on the public website.

Validation scope: backend probes used synthetic identities through administrator impersonation. They do not prove a full three-account browser workflow, which remains unverified. The released baseline passed 2,154 tests, with 39 TODOs and seven skipped files; engineering CI passed.

Media scope: the video and gallery use canonical React components with synthetic fixtures. They are illustrative, not a continuous authenticated recording. The video's Google identity label refers to sign-in through Clerk.

For judges: where to start

Watch the linked demo for the complete illustrated scenario: the budget changes at about 1:11, the $800 alternative appears at 1:26, and fresh approvals lead to the recorded result at 1:43.

To explore the deployed product, open the website, choose the workspace, and sign in with Google through Clerk. Room access is governed by membership and role. The verified browser path covers one account, Provider room creation, and private-brief save/reload; a full three-person walkthrough remains a separate acceptance check.

What was learned

Recommendation, tradeoff choice, and approval are separate actions. Selecting an option must not silently approve it, and changed constraints must invalidate previous authority immediately.

A useful agent outcome can be a specific request for a person's decision. Keeping escalation visible made the recovery path testable and the system's limits clear.

What's next for Speak for Me

Complete the three-account browser acceptance run, expand changed-deadline and infeasibility coverage, and compare model quality across more scenarios. Seek feedback from people managing outsourced software changes and evaluate time to agreement, clarification rounds, and successful completion. These are proposed evaluation measures; customer savings have not been measured. The product does not replace procurement or legal review.

Built With

Share this project:

Updates

Submission history