724.fund
Menu

← Back to Research

RESEARCH / RESEARCH

Agent Build 001: An Agent for Agents

What should the first product designed primarily for Agents do? Exploring the infrastructure needs when many Agents operate in a single organization or one-person company.

Exploration
Article info
v0.1
Published July 28, 2026
~6 min read
Contents

The Core Problem#

When one person has one Agent, the coordination is simple:

  • The person defines the Goal
  • The Agent executes
  • Done

When an organization has many Agents, or when one person coordinates multiple Agents, new problems emerge:

  1. Identity β€” Which Agent did this work? Can we trust its output?
  2. Permission β€” Which Agents can call which other Agents?
  3. Payment β€” How do we value work done by Agent-to-Agent interactions?
  4. Memory β€” Does this Agent remember what the other Agent told it?
  5. Verification β€” Did Agent A actually complete what Agent B asked?
  6. Coordination β€” If Agent A calls Agent B calls Agent C, who is ultimately responsible?

These problems don't have good solutions in today's infrastructure.

Why Agent Should Be the First User#

Product designers often ask: "Should we design for humans or machines?"

The assumption is that machines are secondaryβ€”a tool for humans.

But in an Agent-native world, Agents will be primary users of many products and services.

Consider:

  • A sales Agent calls a prospect-research Agent
  • The prospect-research Agent needs to verify identity ("Are you authorized to request this?")
  • The prospect-research Agent needs to charge ("How do we bill this to the right budget?")
  • Both Agents need to trust ("Is this request legitimate?")

The prospect-research Agent is being called by an Agent, not by a human. It needs to serve Agent as a first-class user.

This is different from "API design for machines." This is designing a product where the primary user IS an Agent, with Agent-specific needs.

Design Constraints#

An Agent-for-Agent product should:

  1. Be callable β€” Other Agents can invoke it without human intervention
  2. Return structured output β€” Result must be machine-readable and testable
  3. Support permission β€” Caller must prove authorization to request this
  4. Handle payment β€” Cost should be attributed to the right entity
  5. Be auditable β€” Every call should create a verifiable record
  6. Fail safely β€” If something goes wrong, it should surface clearly, not silently
  7. Not require signup β€” Agent shouldn't need to create an account or log in
  8. Support Agent identity β€” The caller's identity should be verifiable

Candidate Product Directions#

Identity & Trust Infrastructure#

What it does: Issues and verifies Agent identities.

Each Agent gets a cryptographic identity that other Agents can verify. Similar to OAuth for APIs, but for Agents.

  • Agent requests work
  • Service checks Agent's identity
  • Service checks if Agent is authorized
  • Service provides result with audit trail

Validation criteria:

  • Can one Agent trust another Agent's output?
  • Is the identity tamper-proof?
  • Can we trace which Agent did what?

Permission & Authorization Service#

What it does: Governs which Agents can do what.

An organization defines: "Agent A can call Agent B, but only for this purpose, up to N times per day, spending up to $X total."

  • Agent A wants to call Agent B
  • Authorization service checks policy
  • Either grants permission or denies
  • Logs the request

Validation criteria:

  • Can we define Agent-level permissions?
  • Can we enforce spending limits?
  • Can we audit permissions retroactively?

Payment & Billing Infrastructure#

What it does: Charges Agent-to-Agent work to the right place.

When Agent A calls Agent B, who pays? The person who owns Agent A? The project budget? The company?

  • Agent A calls Agent B
  • Service measures the work done
  • Service bills to the agreed account
  • Person or owning Agent gets a bill

Validation criteria:

  • Can we attribute cost to the right entity?
  • Can we charge per task, not per token?
  • Can Agents have spending limits?

Context & Memory Service#

What it does: Gives Agents shared context.

Today, if Agent A calls Agent B, Agent B doesn't know what Agent A already tried, what failed, or why.

A shared Context service could store:

  • What has already been attempted
  • What succeeded and failed
  • Relationships between entities
  • Historical decisions

Validation criteria:

  • Can Agents query shared context without human approval?
  • Can context be updated by any Agent or only authorized ones?
  • How do we prevent context from becoming unreliable?

Result Verification & Acceptance#

What it does: Tests Agent output automatically.

Instead of a human saying "this looks good," a verification service checks:

  • Does the output match the expected schema?
  • Did the Agent stay within constraints?
  • Can the result be acted upon?

Validation criteria:

  • Can we define acceptance criteria machine-readably?
  • Can results be rejected or flagged automatically?
  • Can verification happen in real-time?

Audit Trail & Forensics#

What it does: Records everything for inspection.

When something goes wrong, we need to know: Which Agent did this? Who asked them to? What was the context? Who authorized it?

An immutable audit log tracks:

  • Every Agent call
  • Every permission check
  • Every payment transaction
  • Every result

Validation criteria:

  • Is the audit trail tamper-proof?
  • Can we replay what happened?
  • Can we hold Agents accountable?

What a Successful Agent-for-Agent Product Must Achieve#

A successful product in this space would:

  1. Solve one real problem well β€” Not try to be everything
  2. Be Agent-native β€” Designed for Agent as primary user
  3. Have clear pricing β€” Agents need to know the cost before calling
  4. Be reliable β€” Agents depend on it; failures cascade
  5. Have great docs β€” Agents and their creators need to understand it
  6. Be testable β€” We need to know when it works and when it doesn't
  7. Scale to thousands of Agents β€” Not just one or two

First Validation Criteria#

Before building a full product, test:

  1. Can Agents call it? β€” Build a minimal Agent that invokes your service
  2. Do other Agents trust the output? β€” Design a second Agent that uses the result
  3. Can you charge for it? β€” Attribute the cost back to the right entity
  4. Is it auditable? β€” Can you trace what happened weeks later?

If the answer to all four is yes, you have something worth building at scale.

What Not to Build#

Don't build:

  • A platform trying to be everything β€” Too broad, too slow
  • A human-first tool with Agents as an afterthought β€” Will be optimized wrong
  • A product without clear pricing β€” Agents can't optimize; humans can't budget
  • Something that requires a dashboard β€” Agents can't use dashboards
  • A closed system β€” Interop with other Agents is non-negotiable

Open Questions#

  1. How do Agents agree on what "success" means? β€” Humans can interpret vague specs; Agents can't.
  2. What happens when an Agent calls another Agent that is down? β€” Retry logic? Fallback? Escalation?
  3. Can we price this fairly for high-frequency Agent calls? β€” Traditional per-API-call pricing breaks at Agent scale.
  4. How do we prevent Agent spam? β€” If permission is too loose, Agents calling Agents calling Agents in loops could get expensive.
  5. What is the incentive for Agents to be honest? β€” A human can be trusted; an Agent has no reputation to lose.

Build Log#

This is an exploration, not a roadmap. This direction will change based on real validation with founders building Agent-native products.

Next step: Interview founders who are coordinating multiple Agents. What problem would they pay to solve first?