One of the most overlooked challenges in building AI agents isn't planning.
It's knowing when not to execute a tool call.
Consider this user request:
"Schedule a meeting with Alex tomorrow."
The intent is clear, but several important parameters may be missing:
- What time should the meeting start?
- How long should it last?
- Which calendar should be used?
- Is Alex's contact information available? If an agent guesses these values, it might schedule the wrong meeting.
If it calls the calendar API with incomplete arguments, the operation might fail entirely.
So how should developers handle this?
- Validate Before Execution A reliable tool-calling workflow should distinguish between three situations:
Ready to execute: All required parameters are available, and the action is authorized.
Needs clarification: Information required for execution is missing or ambiguous.
Cannot proceed: The request is invalid, unsupported, or unauthorized.
This decision should happen before executing a state-changing operation.
- A Simple Parameter Validation Example Suppose a scheduling tool requires a participant, start time, and end time.
We can represent those requirements using Pydantic:
from datetime import datetime
from pydantic import BaseModel, ValidationError, model_validator
class MeetingRequest(BaseModel):
participant: str
start: datetime
end: datetime
@model_validator(mode="after")
def check_time_range(self):
if self.end <= self.start:
raise ValueError("End time must be after start time")
return self
def validate_request(data):
try:
request = MeetingRequest.model_validate(data)
return {"status": "ready", "request": request}
except ValidationError as exc:
return {
"status": "needs_review",
"errors": exc.errors(include_url=False)
}
The validation step detects missing fields and invalid time ranges.
However, validation errors should not automatically trigger a tool retry.
The agent must first determine whether the error can be resolved from authorized context or whether it needs to ask the user.
- Add a Clarification Step For example, the initial request might contain: { "participant": "Alex", "start": null, "end": null } Instead of inventing meeting times, the agent should ask: "What time would you like to meet Alex, and how long should the meeting last?"
After receiving the answer, it can rebuild the request and validate it again.
A simplified workflow looks like this:
User Request → Extract Parameters → Validate → Clarify if Needed → Authorize → Execute → Verify
This helps separate natural-language interpretation from external execution.
- Avoid Over-Clarification Asking questions isn't always necessary.
An agent may be able to use an existing preference, such as a previously authorized default meeting duration.
But there's an important difference between:
- Applying an authorized user preference
- Retrieving an existing value from trusted context
- Guessing an unknown parameter An agent should not silently convert uncertain assumptions into confirmed facts.
Good clarification logic is selective, not excessive.
- Verification Still Matters Even a fully validated tool call can fail.
An API may time out, a calendar event may be rejected, or the wrong external state may be updated.
That's why parameter validation is only one part of reliable execution.
The workflow also needs error handling, authorization checks, and outcome verification.
- What We're Exploring at HEELO At HEELO, we're developing an execution layer for AI agents, with a focus on tool integration, multi-step workflows, and reliability testing.
Through local diagnostic testing, we've investigated failure scenarios involving missing calendar parameters.
These experiences highlight why agent systems need careful validation before interacting with external tools.
HEELO is still under development, and these design considerations are part of our ongoing exploration.
A reliable AI agent shouldn't just know how to call a tool. It should know when it has enough information to call it correctly.
🚀 HEELO — From Talking to Doing.
Website: https://heelo.dev
Discussion
How do you handle missing tool parameters in your AI agent projects?
Do you use JSON Schema validation, Pydantic, LLM-based clarification, or a combination of these approaches?
I'd love to hear what has worked in your implementations.
Top comments (1)
The distinction between ready, needs clarification, and cannot proceed is the part I would keep in production, because it stops a missing field from becoming a silent wrong action. In practice I would also record the original request and every clarification answer together, so a later audit can show exactly what was assumed and what was confirmed. How do you decide when a default is safe enough to apply without asking, versus when the cost of getting it wrong justifies interrupting the user?