How can an agent estimate whether a plan is feasible?

An AI agent can estimate whether a plan is feasible by checking whether every important step has the required inputs, tools, permissions, resources, dependencies, and enough time or budget to complete successfully.

Feasibility asks a practical question:

“Can this plan actually be executed under the current conditions?”

Start with the required capabilities

The agent should check whether it has the tools or actions needed for each step.

For example, a plan may require:

1. retrieve customer data
2. generate a report
3. email the report

If no email tool is available, the plan is not fully feasible as written.

The agent may need to choose another delivery method or ask for help.

Check required inputs

Every step may require specific information.

For example:

book_flight

• destination
• travel date
• passenger details

If essential inputs are missing and cannot be obtained, the plan may not be executable.

The agent should distinguish between:

• information already available
• information that can be retrieved
• information that only the user can provide

Check dependencies

A step may be technically possible but still impossible to run at the current point in the plan.

For example:

retrieve invoices requires customer_id.

If no earlier step produces customer_id, the plan has a missing dependency.

Feasibility therefore depends on whether outputs from earlier steps can satisfy inputs required later.

Check permissions and approvals

The agent may have access to a tool but not permission to perform a particular action.

For example:

• reading an order may be allowed
• cancelling the order may require approval

A feasible plan must account for:

• user permissions
• tenant boundaries
• action-level authorization
• required approvals

If approval can be requested, the plan may still be feasible but conditional.

Check external resource availability

Some plans depend on resources outside the agent.

Examples include:

• inventory
• available meeting slots
• external APIs
• database access
• payment services
• compute capacity

Suppose the goal is to schedule a meeting tomorrow, but no participant has an available slot.

The requested plan may not currently be feasible.

Estimate time and deadlines

A plan may be logically correct but impossible within the required time.

For example:

Goal: Produce a result within 2 minutes.

Proposed plan:

• run a 10-minute batch job
• wait for completion
• analyze output

The agent should recognize that the plan cannot satisfy the deadline.

Time estimates do not need to be perfect; even rough bounds can reject obviously unrealistic plans.

Consider cost and usage limits

The agent may also need to estimate:

• API costs
• token usage
• compute usage
• tool-call limits
• rate limits
• user-defined budget

A technically possible plan may still be infeasible if it exceeds the allowed budget or quota.

Check whether the goal and constraints conflict

Sometimes no plan can satisfy all requested conditions.

For example:

“Book the cheapest direct flight under ₹3,000 for tomorrow.”

If no direct flight exists within that budget, the agent should not pretend the plan is feasible.

Instead, it should identify which constraint cannot be satisfied and ask whether it can be relaxed.

Account for uncertainty

Feasibility is often probabilistic rather than absolute.

For example, a plan may depend on:

• an API that occasionally fails
• an approval that may be rejected
• inventory that can change
• an external job with variable duration

The agent can classify feasibility as something like:

• clearly feasible
• feasible with conditions
• uncertain
• currently infeasible

This is more useful than treating feasibility as always yes or no.

Use cheap checks before expensive actions

The agent should validate important assumptions early.

For example, before building a complex purchase workflow, it may first check:

• product exists
• inventory is available
• user has permission
• budget is sufficient

These inexpensive checks can prevent wasted work later.

Evaluate alternative paths

If one plan is infeasible, another may work.

For example:

Plan A: use preferred shipping provider

If that provider is unavailable:

Plan B: use an approved secondary provider

Feasibility checking should therefore consider whether a valid alternative route exists.

Feasibility should be checked again during execution

A plan that was feasible initially may stop being feasible.

For example:

• inventory becomes unavailable
• permissions change
• a deadline becomes impossible
• an API reaches its rate limit

The agent should reassess feasibility when important state changes.

Deterministic checks are valuable

Important feasibility checks should use trusted system logic where possible.

Examples include:

• tool availability
• permission checks
• required-field validation
• quota checks
• deadline comparisons
• dependency checks

The model can help reason about the plan, but hard constraints should be enforced by code or policy.

A practical feasibility checklist

Before executing a plan, the agent can ask:

1. Are all required inputs available or obtainable?
2. Are all required tools available?
3. Are dependencies satisfiable?
4. Are permissions and approvals obtainable?
5. Are required external resources available?
6. Can the plan finish within the deadline?
7. Is the estimated cost within limits?
8. Does any constraint contradict another?
9. Is there an acceptable fallback for uncertain steps?
10. Is there still a realistic path to the completion condition?

In short

An agent estimates plan feasibility by checking whether the proposed steps can realistically be executed with the available information, tools, permissions, resources, time, and budget.

If important prerequisites cannot be satisfied, the agent should revise the plan, choose an alternative, ask for missing information, or explain that the goal is currently infeasible rather than attempting an impossible workflow.