Agent-to-Agent Phone Calls: The First True AI Negotiation Loop
Your orchestrator says "book a table." Our agent pushes back: "What date? How many people? Under what name?" The orchestrator answers. The call happens. If the task fails, both agents analyze the transcript and decide what to change. Two AI systems negotiating scope, filling gaps, and coordinating real-world execution — no human in the loop.
Why This Is Different
Most AI "phone call" APIs are fire-and-forget. You send a task, the agent dials, and you get whatever comes back. If the task was vague, the agent improvises. If the line is busy, you get a failure. If the task fails, you get "FAILED" and nothing else.
That's a tool call, not a collaboration. Real multi-agent systems need agents that can negotiate with each other — question ambiguous instructions, fill in gaps before acting, handle transient failures gracefully, and provide enough context on failure for the other agent to adapt.
This is what Sats4AI's AI Call now does. It's not just an endpoint — it's a counterparty that your orchestrator can reason with.
The Negotiation Loop
Here's what happens when an orchestrating agent sends a task that's missing critical information:
"Book a table at Mario's Restaurant, phone +1-555-0123"
Sends task via ai_call (MCP) or POST /api/l402/ai-call
"Hold on — I need more info before I call."
Returns state: "pending_confirm" + questions: ["What date?", "What time?", "How many people?", "Under what name?"]
"Friday March 28, 7pm, 4 people, under Nakamoto"
Calls confirm_ai_call with answers (MCP) or POST {action:"confirm"} (L402)
Call initiated. Polling for results...
Returns state: "calling", call_id, poll_url
Voicemail detected. Retrying in 2 minutes... (attempt 2/3)
Transparent to orchestrator — just keep polling
Call complete. Here's the full transcript and analysis.
Returns transcript, call_analysis, task_completed: true/false, disconnection_reason
No human touched this interaction. The orchestrator reasoned about the questions, formulated answers from its context, and the call proceeded with complete information. This is agent-to-agent negotiation.
Three Capabilities That Make This Work
1. Push-Back: Pre-Flight Task Analysis
Before dialing, the system analyzes the task for missing critical information. If it detects gaps — a booking without a date, a cancellation without a reference number, a task too vague to act on — it returns clarification questions instead of proceeding blindly.
The orchestrating agent receives the questions, reasons about them using whatever context it has (user conversation, database, calendar), and sends back answers. The task is enriched with the new information and the call proceeds.
What triggers push-back:
- • Task too short (<20 characters) — not enough detail to act on
- • Booking/reservation missing date, time, party size, or name
- • Cancellation missing name or reference number
- • Any task the heuristic engine flags as under-specified
2. Auto-Retry: Transparent Failure Recovery
Real phone calls fail for mundane reasons — voicemail, busy signal, no answer, immediate hangup. These aren't task failures. They're transient infrastructure issues that a human would handle by calling back.
The system now retries automatically, up to 3 attempts, included in the original payment. The orchestrating agent doesn't need to handle retry logic — it just keeps polling and sees the final result.
3. Rich Failure: Transcript + Analysis for Agent Reasoning
When the call connects but the task isn't completed — the restaurant is closed, the person put us on hold too long, the wrong department answered — the API doesn't just return "FAILED." It returns everything:
- •Full transcript — every word spoken by both sides
- •Call analysis — structured summary of what happened
- •Disconnection reason — why the call ended
- •task_completed: false — explicit flag
The orchestrating agent reads the transcript, reasons about what went wrong, and can try again with an adjusted task and a new payment: "Add 5 more minutes to handle hold time," or "Try again Monday morning when they're open," or "Ask for the reservations desk specifically."
Why This Is Negotiation, Not Just an API Call
A regular API call is one-directional: send request, get response. What happens here is fundamentally different. Two AI systems are engaged in a multi-turn interaction where both sides have agency:
The orchestrator reasons about scope
It doesn't just blindly forward user instructions. When push-back questions arrive, the orchestrator draws on its full context — prior conversations, calendars, databases — to formulate complete answers. It decides what information to share and how to phrase it.
The execution agent refuses to act blindly
Instead of improvising when critical info is missing, it identifies exactly what's needed and asks. This is the AI equivalent of a contractor saying "I can't start without the blueprints" instead of guessing at the floor plan.
Failure becomes a feedback loop
When a task fails, both agents have the transcript. The orchestrator can analyze what happened, adjust its approach, and try again. "They said they're closed on Sundays — let me reschedule for Monday." The second attempt benefits from the first.
Infrastructure is invisible
Auto-retries on voicemail, smart delays, retry tracking — the orchestrator doesn't manage any of this. It focuses on task-level reasoning while the execution layer handles phone-system reality.
How to Use It
MCP and L402 — same capabilities, two protocols
Via MCP (Model Context Protocol)
# Step 1: Pay
create_payment({ toolName: "ai-call", phone_number: "+15550123",
duration_minutes: 3 })
# => { paymentId, invoice, amountSats }
# Step 2: Send task (may push back)
ai_call({ paymentId, phone_number: "+15550123",
task: "Book a table at Mario's" })
# => { state: "pending_confirm", session_id: "abc-123",
# questions: ["What date?", "What time?",
# "How many people?", "Under what name?"] }
# Step 3: Answer push-back
confirm_ai_call({ sessionId: "abc-123",
answers: { "What date?": "Friday March 28",
"What time?": "7:00 PM",
"How many people?": "4",
"Under what name?": "Nakamoto" } })
# => { state: "calling", call_id: "call_xyz", session_id: "abc-123" }
# Step 4: Poll
check_job_status({ requestId: "call_xyz", jobType: "ai-call" })
# => { status: "IN_PROGRESS" } ... or "RETRYING (2/3)" ...
# Step 5: Get result
get_job_result({ requestId: "call_xyz", jobType: "ai-call" })
# => { status: "COMPLETED", task_completed: true,
# transcript: "Agent: Hi, I'd like to book a table...",
# call_analysis: { summary: "Reservation confirmed for..." } }Via L402 (HTTP Lightning Auth)
# Step 1: POST with L402 auth (may push back)
curl -X POST https://sats4ai.com/api/l402/ai-call \
-H "Authorization: L402 <macaroon>:<preimage>" \
-d '{"phone_number":"+15550123",
"task":"Book a table at Mario\'s"}'
# => { state: "pending_confirm", session_id: "abc-123",
# questions: ["What date?", ...] }
# Step 2: Confirm with answers (no re-auth needed)
curl -X POST https://sats4ai.com/api/l402/ai-call \
-d '{"action":"confirm", "session_id":"abc-123",
"answers":{"What date?":"Friday March 28", ...}}'
# => { state: "calling", call_id: "call_xyz", poll_url: "..." }
# Step 3: Poll
curl "https://sats4ai.com/api/l402/ai-call?call_id=call_xyz"
# => { status: "ended", task_completed: true, transcript: "...",
# call_analysis: {...} }When the Task Fails: Agent Adaptation
The real power shows on failure. Here's what a failed call result looks like, and how an orchestrator might respond:
{
"status": "COMPLETED",
"task_completed": false,
"transcript": "Agent: Hi, I'd like to book a table for 4 on Friday.
Host: I'm sorry, we're fully booked Friday evening.
Agent: Is Saturday available?
Host: We have a 7:30 opening Saturday.
Agent: Let me check with my client. I'll call back.
Host: Sure, we'll hold it for 30 minutes.",
"call_analysis": {
"summary": "Restaurant fully booked for requested date.
Saturday 7:30 PM available, held for 30 minutes."
},
"disconnection_reason": "agent_hangup",
"message": "Task was not completed. Review the transcript
to understand what happened. You can retry with a new
payment — adjust your task based on the call results."
}What a smart orchestrator does with this:
"Friday is full but Saturday 7:30 works and they're holding it for 30 minutes. I'll confirm with the user, then immediately call back to lock in Saturday." — Or if running autonomously: creates a new payment, adjusts the task to "Confirm the Saturday 7:30 reservation for 4 under Nakamoto," and calls again. Two agents collaborating to get the job done.
Real Use Cases
Travel agent orchestrator
Books flights via API, then calls hotels and restaurants to complete the trip. Push-back catches missing check-in dates. Auto-retry handles front desk voicemail. Transcript analysis reveals the hotel is sold out, triggering a search for alternatives.
Personal assistant
User says "cancel my dentist appointment." The orchestrator knows the user's name but not the appointment date. Push-back asks for it. The orchestrator checks the calendar, finds it, and confirms. Call proceeds with complete information.
Business process automation
Verifies vendor information by calling and asking specific questions. If the first call gets a receptionist who transfers to voicemail, auto-retry calls back. If the vendor gives partial info, the transcript feeds back into the next call with more targeted questions.
Customer service escalation
When an automated system can't resolve an issue, the orchestrator calls the provider. If the first attempt hits a long hold and times out, the failure transcript shows the hold music duration. The retry uses more minutes and calls during off-peak hours.
A Look Into the Future of Orchestrators
The agent ecosystem is moving from single-agent demos to multi-agent production systems. The missing piece has been the interaction layer — how agents communicate with each other across organizational boundaries, negotiate scope, handle failures, and coordinate real-world actions.
This is infrastructure that enables agents to be true counterparties, not just passive tools. When your orchestrator can push back and forth with an execution agent, handle retries transparently, and adapt based on rich failure data — you're not calling an API anymore. You're running a distributed multi-agent system where each node has genuine agency.
And the entire interaction is settled in real-time with Lightning micropayments. No contracts, no accounts, no invoicing. The payment is as autonomous as the agents.
The First Agent-to-Agent Negotiation Loop — Live Now
Available via MCP and L402. A few sats per call. No signup, no API keys.