DEV Community: Haley

Design the Moment an AI Agent Needs Human Input

Haley — Fri, 10 Jul 2026 10:08:59 +0000

An AI agent asking a question is not a conversational flourish. It is a handoff of responsibility.

The system has reached a boundary it cannot—or should not—cross alone. The interface must explain the decision, preserve the work already completed, make the consequence of each answer visible, and resume without creating a second task.

Many products design this moment as another chat bubble. That works only when the person is already watching. Long-running tasks need an interruption contract that survives closed tabs, mobile notifications, time zones, and expired context.

Model the handoff as a flow

agent working
     |
     v
decision boundary detected
     |
     +--> preserve checkpoint and evidence
     |
     v
needs human input ----> notify through allowed channel
     |                           |
     |                           v
     |                    user opens exact task
     |                           |
     +<--------------------------+
     |
     v
answer reviewed + authorization rechecked
     |
     +--> expired / unauthorized --> explain and recover
     |
     v
resume same task from checkpoint

This separates a question from a chat message. A question changes task state, may pause resource consumption, and needs an explicit resume rule.

Every interruption needs six fields

Field	What the user needs to know
Decision	The smallest question that unblocks work
Reason	Why the system cannot safely choose
Evidence	Files, logs, diff, policy, or preview that informs the answer
Consequence	What each choice permits or changes
Expiry	When the answer becomes stale or the task will stop
Recovery	What happens if the user declines, delays, or lacks permission

Compare two versions:

Weak: Which branch should I use?

Stronger: Choose the target branch for the authentication patch.
main is protected and will open a pull request; release/2.4 will create
a patch against the active release. No files have been changed yet.
This question expires if the repository revision changes.

The stronger version helps someone decide without reconstructing the whole task from memory.

Distinguish questions, approvals, and confirmations

These interactions have different risk:

Type	Example	Design requirement
Clarifying question	Which branch?	Preserve context and allow a reversible answer
Approval	May the task run a migration?	Show scope, side effects, identity, and expiry
Confirmation	Discard partial changes?	State irreversible loss and safer alternatives
Credential request	Connect repository access?	Use a trusted auth flow; never ask for a secret in chat

Calling every case “needs input” is acceptable as a backend state, but the interface should not style a low-risk clarification like a production approval.

Design the notification as a pointer, not the decision surface

A notification should contain enough information to prioritize, but sensitive evidence and irreversible actions belong behind authenticated access.

Recommended notification structure:

Task needs input: Refactor authentication
Decision: choose the target branch
Waiting since: 14:32
Open task

Avoid putting repository contents, patches, credentials, or an “approve” action directly on a lock screen. When the user follows the link, recheck account, role, task version, and whether the decision is still active.

Make waiting and expiry visible

The agent's state should answer:

Is compute still running while it waits?
Are partial changes saved?
Can another authorized teammate answer?
Will the task time out?
What event would make the question stale?

Useful copy:

Waiting for a branch choice. The workspace is paused and partial analysis
is saved. Anyone with Maintainer access can answer. This decision expires
when the repository revision changes or after 24 hours.

The exact timeout is a product policy. The design requirement is to expose it before expiry, not reveal it after the task disappears.

Resume without erasing the handoff

After an answer, preserve an event such as:

14:32 Agent requested target branch
14:47 Mina selected release/2.4
14:47 Authorization checked: Maintainer
14:48 Task resumed from checkpoint 7

The history establishes who made the decision and which task version consumed it. It also supports recovery when the agent fails later: the user should not have to answer the same unchanged question again.

If the repository or policy changed while the task waited, reject the stale answer gracefully:

This choice is no longer current because the repository changed at 14:45.
The task preserved its analysis and needs a new target-branch decision.

A lightweight evaluation script

Test the flow with five scenario prompts, not a generic “does this feel clear?” interview:

The user sees the question immediately while working on desktop.
The user opens it three hours later from a mobile notification.
A teammate without permission follows the task link.
The repository changes before the answer is submitted.
The task fails two steps after resuming.

For each scenario, ask the participant to explain:

what the agent has completed;
why it stopped;
what each available action will do;
whether anything is currently consuming resources;
how to decline or safely leave;
how they would find the decision later.

Measure decision accuracy, time to the correct evidence, accidental approval attempts, and whether the participant can predict the resume behavior. Do not invent sample results; report participant count, recruitment, task fixture, and raw failure categories when the study is actually run.

Applying the pattern to a documented task workspace

The public MonkeyCode repository describes AI task management, project requirements, cloud development environments, and PC/mobile synchronization. Those documented workflows make asynchronous human input a relevant design question. The flow above is a design proposal, not a claim that MonkeyCode currently uses these exact states, notifications, or expiry rules.

Disclosure: I contribute to the MonkeyCode project. Product context is based on the linked public documentation; no user study results are claimed here.

Designers and developers can join the MonkeyCode Discord to discuss how task handoffs should work. People interested in evaluating the hosted service can also ask the team about current free model-credit availability, eligibility, and limits.

The moment an agent stops is not empty time. It is a transfer of authority. Design that transfer with the same care as the action it may authorize.

Design AI Output for Correction, Not Passive Acceptance

Haley — Fri, 10 Jul 2026 07:12:16 +0000

An AI interface often presents uncertain output with the visual confidence of ordinary software: a polished paragraph appears in the same place as a deterministic result. A small disclaimer cannot carry the full burden of explaining that the content may be incomplete, unsupported, or inappropriate for the current situation.

The interaction should make checking and correction part of the normal task.

Identify the decision around the output

Before choosing components, map what happens next:

generated draft → user reviews → user edits → user confirms → system acts

Then ask:

Can a weak result be detected by this user?
What source material is available for checking it?
Is the next action reversible?
Who is affected if the result is wrong?
Does the user have time and authority to review it?

A draft email and an automatically rejected application may use similar model technology but require completely different interaction safeguards.

Match presentation to the output’s role

Use a component that communicates what the result is:

Draft: editable content with a visible unsent state.
Suggestion: an option that does not replace the user’s existing value until accepted.
Classification: a label plus confidence-relevant evidence and an override.
Answer from sources: a response with passage-level references and a “not found” state.
Proposed action: a preview of the exact effect, followed by confirmation.

Avoid placing generated text directly into a final, authoritative field. If the user is expected to review it, the design should support comparison and editing rather than hide those steps behind an “AI generated” badge.

Put evidence next to the claim

When the system retrieves sources, show which source supports which part of the answer. A list of links at the bottom makes users hunt for the relationship.

A practical pattern is a claim with an adjacent source control:

The account was upgraded on 8 July.  [Source: account event 1842]

Selecting the source opens the relevant passage, not merely the top of a long document. If no supporting passage exists, say so. Do not fabricate a citation or substitute a generic link.

Evidence display also needs access control. A source title or snippet can leak information even when the linked document later returns “forbidden.” Filter before generation and before rendering citations.

Design correction as a first-class path

Correction should preserve momentum:

let users edit a draft in place;
provide undo after applying a suggestion;
keep the original value available for comparison;
support rejecting one part without discarding the whole result;
preserve user changes when regeneration occurs;
ask what was wrong only when feedback is useful and optional.

Be careful with “Regenerate.” It often replaces one opaque result with another and can erase useful edits. Offer targeted controls such as “shorter,” “change tone,” or “retry this section” only when their behavior is clear.

Do not treat acceptance as proof of correctness. Users may accept because reviewing is difficult, the interface is persuasive, or they believe disagreement will be penalized.

Use confirmation to reveal consequences

Confirmation is valuable when it adds information, not when it repeats “Are you sure?”

Before a consequential action, show:

the exact recipients, records, or systems affected;
the generated content that will be sent or written;
any missing required fields;
whether the action can be undone;
which identity will perform it.

Keep generation and execution separate. “Create a response” should not also send it. If the product needs automation, define bounded rules and a visible activity history.

Explain uncertainty locally

A permanent warning banner becomes easy to ignore. Put guidance at the point where it changes a decision:

“Draft—review before sending” beside the send control;
“No supporting source found” where an answer would appear;
“Still generating” on incomplete streamed content;
“Three records could not be classified” beside the affected rows;
“This action cannot be undone” in the confirmation step.

Avoid vague confidence percentages unless the number is calibrated for the exact task and users understand what it predicts. “82% confident” does not explain whether the missing 18% concerns a harmless phrase or a critical account detail.

Make refusal and failure different

Users need distinct recovery paths for:

insufficient information: add a source or clarify the request;
policy refusal: explain the relevant boundary and allowed alternatives;
technical failure: retry or continue manually;
permission failure: request access or choose an authorized source;
cancelled work: keep input and any clearly labeled partial result.

One generic error message hides the next step. It also makes research data less useful because very different events collapse into “AI failed.”

Evaluate the interaction, not only the answer

Output quality tests should be paired with task-level research. Observe whether users:

notice unsupported claims;
find and understand sources;
can make a partial correction;
know whether content is final or still streaming;
understand what confirmation will do;
recover after refusal, cancellation, or timeout;
retain meaningful control under time pressure.

Include accessibility in the study. Streaming announcements, focus movement, source popovers, difference views, and drag-only interactions can change who is able to review the result.

The paper Guidelines for Human-AI Interaction reports an evidence-based set of guidelines organized around initial use, regular interaction, failure, and change over time. It is a useful prompt for reviews, but the right design still depends on the task’s consequences and the user’s ability to evaluate the system.

Uncertainty does not have to become a vague warning. It can shape the workflow: evidence near claims, edits before action, meaningful confirmation, reversible changes, and specific recovery. Those patterns make user control observable rather than ceremonial.

Gradium Raised $100M to Build AI Voice Agents — The Voice AI Race Is Heating Up

Haley — Fri, 10 Jul 2026 04:36:26 +0000

Gradium, a Paris-based AI startup, just raised over $100 million in a round backed by Nvidia. Their focus: AI voice agents that can handle phone calls, customer service, and real-time conversations.

Voice AI is having a moment. And it's about to change how businesses interact with customers.

What Gradium does

Gradium builds AI agents that can have natural phone conversations. Not the robotic "press 1 for sales" IVR systems — actual conversations where the AI understands context, handles interruptions, and responds naturally.

Use cases they're targeting:

Customer service: Handle routine inquiries without human agents
Appointment booking: Schedule, reschedule, cancel via natural conversation
Sales calls: Initial outreach and qualification
Surveys and feedback: Collect data through conversational interfaces

The technology has improved dramatically in the past year. Latency is down, accuracy is up, and the voices sound increasingly human.

Why $100M matters

This isn't just about Gradium. It's a signal that voice AI is investable at scale.

Other players in the space:

ElevenLabs: Raised $80M for voice synthesis
PlayHT: Voice cloning and generation
Vapi: Developer-focused voice AI platform
Retell: Voice agent infrastructure
Google: Duplex and Contact Center AI
Amazon: Alexa and Lex

The market is crowded, but the opportunity is massive. Customer service alone is a $350 billion industry globally. Even capturing 5% of that creates a multi-billion dollar company.

The technical challenges

Voice AI is harder than text AI for several reasons:

Latency: Humans expect responses within 200ms. Current AI takes 500ms-2s.
Interruptions: People talk over each other. AI needs to handle this gracefully.
Context: Phone conversations have noise, accents, and unclear speech.
Emotions: Detecting and responding to emotional cues in voice.
Reliability: Business calls can't have AI hallucinations or errors.

Gradium's pitch is that they've solved these problems better than competitors. The $100M suggests investors believe them.

The human cost

Here's the uncomfortable part: voice AI will replace human jobs.

Customer service representatives, call center agents, receptionists — these roles are directly threatened by voice AI. The World Economic Forum estimates 85 million jobs could be displaced by AI by 2025, and voice AI is a significant driver.

The counter-argument: voice AI creates new jobs (AI trainers, prompt engineers, system maintainers) and frees humans for higher-value work.

But that's cold comfort if you're a call center agent in a developing country where these jobs are a lifeline.

The privacy angle

Voice AI raises serious privacy concerns:

Recording: These systems record and process conversations
Storage: How long is audio retained? Where?
Analysis: What else is done with the voice data?
Consent: Do callers know they're talking to AI?

Some jurisdictions require disclosure when AI is used in calls. Others don't. The regulatory landscape is messy and inconsistent.

What this means for developers

If you're building products that involve voice:

Voice AI is accessible now: APIs from Gradium, Vapi, Retell make it easy to add voice
Quality expectations are high: Users won't tolerate robotic-sounding agents
Latency matters: Optimize for sub-500ms response times
Fallback to human: Always have an escalation path to human agents
Compliance: Check local laws about AI disclosure in calls

I've been experimenting with voice AI for some internal tools. The technology is impressive, but the UX challenges are significant. Small mistakes feel much bigger in voice than in text.

My take

Voice AI is inevitable. The question is whether we implement it responsibly.

Companies that use voice AI to enhance human agents (not replace them) will build better customer relationships. Companies that use it purely to cut costs will damage their brands.

The best approach: voice AI handles routine tasks, humans handle complex or emotional situations. That's a win for efficiency and for customer experience.

Tools like MonkeyCode are helping developers build better AI systems by catching issues early. The same principle applies to voice AI — build with quality from the start, don't bolt it on after problems emerge.

What's next

Expect voice AI to become ubiquitous in the next 2-3 years:

Most customer service calls will start with AI
Phone-based sales will be largely automated
Voice interfaces will replace many text-based interactions
Real-time translation will enable cross-language phone calls

The $100M isn't just for Gradium. It's a bet that voice is the next major AI interface.

Have you interacted with AI voice agents recently? How was the experience?

Prime Intellect Raised $130M to Build AI Agents — But Who's Accountable When They Break?

Haley — Thu, 09 Jul 2026 11:49:04 +0000

Prime Intellect just raised $130 million to help enterprises build their own AI agents. The pitch sounds amazing: autonomous AI that handles tasks, makes decisions, and frees up human workers for "higher-value work."

But here's the question nobody's asking: when an AI agent makes a mistake, who's responsible?

The Accountability Vacuum

Let's imagine a realistic scenario:

Your company deploys an AI agent to handle customer refunds
The agent approves a $50,000 refund that shouldn't have been approved
The customer cashes out and disappears
Your boss asks "who approved this?"

The answer: nobody. And everybody.

The AI company says "we just provide the tool"
Your IT team says "we just deployed it"
Your business team says "we just defined the requirements"
The AI agent says... nothing, because it's code

This is the accountability vacuum. And it's going to get worse.

Why Enterprise AI Agents Are Different

Consumer AI (ChatGPT, Claude) is mostly used for:

Writing emails
Summarizing documents
Answering questions

The stakes are low. If ChatGPT writes a bad email, you rewrite it.

Enterprise AI agents handle:

Financial transactions
Customer data access
System configurations
Business decisions

The stakes are much higher. And yet, we're deploying them with the same "move fast and break things" mentality.

The Three Problems Nobody's Solving

1. Decision Audit Trails

When an AI agent makes a decision, can you reconstruct why? Most AI systems are black boxes. Good luck explaining to a regulator why your agent flagged 10,000 accounts as suspicious.

2. Error Recovery

When a human makes a mistake, you can:

Ask them what happened
Retrain them
Fire them if necessary

When an AI agent makes a mistake:

You can't interview it
Retraining means rebuilding
"Firing" means redeploying (with the same bugs)

3. Liability Allocation

If your AI agent violates a regulation, who pays the fine?

The AI provider? (They'll say they're just a tool)
Your company? (They'll say the AI was autonomous)
The user who configured it? (They'll say they didn't know)

Right now, the answer is: the company deploying it. Always.

The Right Way to Build Enterprise AI

This isn't an argument against AI agents. They're incredibly useful. But we need to build them responsibly:

Human-in-the-Loop by Default

Every high-stakes decision should require human approval. Not as a fallback — as the default.

Complete Audit Logging

Every AI decision should be logged with:

Input data
Decision made
Confidence level
Reasoning (if available)

Graduated Autonomy

Start with AI suggesting decisions, not making them. As trust builds, gradually increase autonomy — with guardrails.

This is where tools like MonkeyCode get it right. Instead of promising "fully autonomous AI," they focus on:

Augmenting human capability, not replacing it
Transparent decision-making, not black boxes
User control, not autonomous agents

The philosophy is simple: AI should make humans more effective, not replace human judgment.

The Bottom Line

Prime Intellect's $130M raise shows that enterprise AI agents are inevitable. But "inevitable" doesn't mean "ready."

Before we hand the keys to AI agents, we need to answer the accountability question. Because right now, when things go wrong, the only answer is: "¯_(ツ)_/¯"

And that's not good enough for enterprise.

Would you trust an AI agent to handle financial decisions at your company? What safeguards would you need? Let's discuss. 👇