Product.ai / Join / Projects / The Agent Developer as Buyer — Pre-Purchase Verification Behavior in Agent-Originated Commerce
Project

The Agent Developer as Buyer — Pre-Purchase Verification Behavior in Agent-Originated Commerce

Product.ai's agent-economy pillar rests on the thesis that agents and their developers will hire Product.ai's verified-truth API as the verification layer in agent-originated commerce. The agent-commerce kernel articulates three buyer types (consumer shoppers, AI agents + their developers, merchants/affiliates), with substantively different research methodologies and trust mechanics for each. We have research direction on the consumer (PRJ-56/57/58), no published research on the agent developer, and no methodology in place for studying the agent itself as a calling entity. Specifically: at what false-positive rate does an agent stop calling a verification API? Which Confident No structures earn highest tool-trust scores within the kernel-named Triple Binary Gate (A-4)? How does an agent developer evaluate "trust" in a Truth API differently from how a consumer evaluates trust in a chat verdict? Without this research, the MCP roadmap (Beat 2 / Q3 2026 expansion) is built on inherited assumptions from B2B SaaS playbooks that do not apply to verification-layer products.
Project Overview
Discipline
user-researcher
Duration
3 weeks
Compensation
Your stated freelance rate
Surface
Agent commerce · Product.ai · Truth Graph
Kernels
agent-commerce · productai · truth-graph
Outcomes
dev-integrate · agent-route · checkout-intel
Tier
Consequential
Tooling
Claude Code or Co-work

Why we want this done

This project derives from agent-commerce-kernel A-3 (Offensive tools are the moat — must be calibrated to real agent-developer buying behavior), A-4 (Triple Binary Gate — the schema/latency/error mechanics decide whether tools survive), and A-8 (Trust compounds logarithmically, collapses exponentially — Honey collapse pattern applies to API consumers as much as consumers). Truth-graph-kernel A-7 (Glass Box — evidence trace for agents to cite) and productai-kernel A-10 (Truth Layer in Agent Stack) are direct kernel anchors. The work serves dev-integrate, agent-route, and checkout-intel outcomes. The 12-18 month standard-setter window (kernel constraint) is closing; without empirical buyer-side research on agent developers, every MCP product decision is a hypothesis. Agent developers are a 25-person company's lowest-research-coverage buyer type and the highest-revenue-per-customer one — the asymmetry is acute.

Scope

  • Agent developer cohort: identify and interview 6-10 working agent developers across the three sub-types named above. Recruitment is part of the work.
  • MCP tool simulation: coordinate with the MCP tool lead to run simulated workloads against varied false-positive rates and varied Confident No structures. Engineering-adjacent (not engineering-led).
  • aios/kernels/agent-commerce-kernel.md: propose Signal updates (S-1, S-2, S-3) based on findings. Route via /strategy-sync if forged into axiom.
  • aios/outcomes/dev-integrate.md and agent-route.md and checkout-intel.md: the project's findings may revise evidence criteria. Route via /outcomes if six-test gate holds.
  • productai-mcp (MCP tool team): the buyer-research artifact becomes input to roadmap. Coordinate Day 1.

What success looks like

A stranger reads the shipped artifact, sees the three-buyer-type taxonomy with named buyer profiles (e.g., "agent-platform-developer at OpenAI/Anthropic/Google", "agent-app-builder shipping consumer agents on top of frontier APIs", "enterprise-agent-integrator deploying internal agents"), follows verification behavior maps for each, identifies the Confident No tolerance threshold with evidence trace, and can use the artifact to make tool-prioritization decisions without asking the team. The MCP roadmap visibly grounds in the artifact. Phil Larsen (Mobile lead, but adjacent to MCP architecture) and the MCP tool lead have read it and acted on at least one decision based on it.

The robust solution may surface a better cut: maybe the meaningful unit is not "buyer type" but "verification-call lifecycle stage" — different verification needs at tool-discovery vs. tool-trust-formation vs. tool-collapse. The candidate is invited to propose. What is non-negotiable: empirical agent developer interviews (6-10 working developers, not just kernel-cited research), simulated agent workloads against actual tool behaviors (engineering-adjacent), and oracle separation (the candidate cannot self-verify the tolerance threshold).

References

references.md
Kernels: aios/kernels/agent-commerce-kernel.md (A-3 Offensive tools moat, A-4 Triple Binary Gate, A-8 Trust compounds logarithmically / collapses exponentially, S-1/S-2/S-3 signals)
Kernels: aios/kernels/productai-kernel.md (A-10 Truth Layer in Agent Stack, A-11 Brand Singularity three layers)
Kernels: aios/kernels/truth-graph-kernel.md (A-7 Glass Box — agents need evidence trace to cite)
Outcomes: aios/outcomes/dev-integrate.md, agent-route.md, checkout-intel.md (the agent-economy outcomes this project serves)
Frontier-practice grounding: axioms/Frontier-Practice-2026/product-management-state-of-practice-2026.md (B2B JTBD methodology), axioms/Frontier-Practice-2026/data-science-state-of-practice-2026.md (simulation methodology, behavioral analytics for non-human agents), axioms/Frontier-Practice-2026/strategy-state-of-practice-2026.md (B2B buyer research).
Anti-references: "User research on agent developers" — applies consumer methodology to B2B technical buyers, REJECT. "Customer development interviews with developers" — interview-shaped, no production tie-in. "Survey of AI engineers" — self-report from a population that knows it's being researched, kernel mistrusts. "Run usability tests on the MCP server" — that's evaluative research on a shipped artifact, this archetype's project is generative buyer research before the artifact ships.
Driver: aios/drivers/operations/recruiting-driver.md §5.1, §5.2 rule 9 (oracle separation), §5.2 rule 10 (external truth anchors).

Constraints

  • Claude Code or Claude Co-work primary substrate.
  • Three-week duration. Day 1 onsite. Optional second onsite mid-trial for MCP roadmap alignment.
  • IP boundary applies (driver §9): trial contractor team membership only, no aios-methods access. The simulation workloads must be designed within trial-contractor scope — coordinate with MCP tool lead on what's feasible.
  • Oracle separation: the candidate cannot self-verify the tolerance threshold. Either Trust Architect-style external concordance (an outside agent developer reviews the methodology) or a separate analytic eye is required.
  • Final deliverable: three-buyer-type taxonomy + agent Confident No tolerance threshold + tool-description/Confident-No structure mapping + decision brief for MCP roadmap. Report-only rejected.
  • No PRD authoring. No tool-specification writing in PRD form. The artifact is research-led — buyer behavior maps that engineers and product team consume, not features they execute.

---

```

---

##

Apply
01

Read the Codex (10 min)

The operating principles we work by. If they resonate, the rest of this will land. Open the Codex →

02

12-minute video screen

Hireflix, async. Questions are calibrated to this project specifically.

03

Chemistry call (30-60 min)

Direct call with the CEO. Strategic alignment and mutual fit. No problem-solving exercise.

04

Project begins within 2-3 weeks

1099 contractor agreement, NDA, paid at your stated rate. Day 1 in Santa Monica.