MyDot Consultancy

Featured image: AI-generated conceptual illustration. Sources checked 26 October 2026.

An agent can produce an impressive plan before discovering that a required file is missing or an integration is read-only. A useful plan must survive that discovery. It should organize work around evidence and constraints, then change when the environment reveals something new.

For a business process, planning is less about generating a long numbered list and more about controlling dependencies. What must be known before an action is safe? Which steps can proceed independently? What would make the goal impossible within the current authority? These questions turn a plan into an operating aid.

Write the objective as a verifiable result

Consider a hypothetical operations team asking an agent to prepare a supplier onboarding packet. “Onboard the supplier” is too broad if the assistant can only gather documents and draft forms. A better objective is to assemble the required documents, identify missing fields and prepare a reviewable packet without submitting it.

That objective names the output and the authority boundary. It also allows a legitimate partial result: a packet with clearly identified gaps. The agent should not fabricate missing bank details or certify a document merely to make the checklist appear complete.

Anthropic’s agent architecture article describes model-directed processes that adapt to intermediate results. Use that as a conceptual reason for revisable planning, not as permission for a system to redefine its business goal when a difficult dependency appears.

Identify prerequisites before dependent work

The supplier packet may depend on a verified legal entity, the applicable region, an approved contact and a current onboarding checklist. If the entity is ambiguous, filling forms immediately can create rework or expose information to the wrong organization. Resolve that prerequisite first.

Other tasks may be independent. The agent can check whether an insurance certificate is present while locating the applicable template, provided both reads are authorized. Planning should distinguish independent evidence gathering from steps that rely on an unresolved decision.

Represent dependencies in plain language. “Draft the payment form only after the legal entity and approved payment instructions are verified” is more useful than “Step four: complete form.” The condition makes it possible to explain why work paused and what would unblock it.

Use milestones that produce evidence

A milestone should leave something inspectable: a document inventory, a resolved entity identifier, a validated field map or a draft packet. “Research supplier” is too vague to establish progress. “Locate the current registration document and record its source” provides a concrete result.

Keep a distinction between an attempted step and a completed one. The agent may have searched a repository without finding the required certificate. Record the search scope and result, then mark the certificate as missing. A plan that checks off work merely because a tool was called conceals important gaps.

The OpenAI Agents SDK execution guide documents the loop through which agents interact with tools. Business milestones sit above that loop: a tool call is an execution event, while a milestone describes what the event established for the task.

Revise the plan for a reason

Suppose the retrieved checklist shows that the supplier’s region requires an additional declaration. The agent should add the missing requirement, explain the source and continue within scope. That is a useful revision because new evidence changed the required work.

Now suppose the assistant encounters a permission error when opening a confidential folder. It should not revise the plan to search an employee’s private files or use another identity. A blocked dependency does not expand authority. The next step may be to request the required document through an approved channel.

Record material plan changes with short explanations. An operator should be able to see whether the change followed new evidence, a user instruction or a failed dependency. Avoid retaining a long self-narration of every thought; preserve the decisions that affect scope, output or risk.

Keep approval outside the model’s assumptions

A plan may include “submit for approval” or “execute approved update.” Those are separate states. A user asking for a packet does not automatically authorize submission, and a reviewer approving one version does not necessarily approve a later version with different details.

The SDK human-in-the-loop guide describes approval-gated execution and resuming paused work. The surrounding application should bind approval to the specific proposed action and preserve the decision when the task resumes. If material details change, the plan should return to review.

Build a plan with explicit stop conditions

• Stop when the requested packet is assembled and the required checks are recorded.
• Pause when a necessary approval has not been granted.
• Mark a blocker when required evidence is unavailable within authorized sources.
• Escalate conflicting authoritative records rather than choosing a convenient version.
• Cancel further work when the user withdraws the request.
• Report partial completion with remaining dependencies instead of claiming success.

These conditions help prevent a plan from becoming a mandate to continue indefinitely. They also make it easier to measure performance. A correctly blocked run can be safer and more useful than a completed-looking packet containing invented information.

Review the plan against one failed scenario

Before deployment, rehearse a supplier with two similar legal names, a missing certificate and a document that changes midway through the task. Ask whether the plan resolves identity, preserves the missing-evidence state and rechecks the changed document before finalizing the packet.

Inspect the final artifact and the progress record together. Do they agree on what was completed? Can a human resume the work without repeating every search? Does the record clearly distinguish facts from proposals? Those checks reveal whether planning is supporting execution or merely decorating it.

A good agent plan is specific enough to guide work and flexible enough to acknowledge reality. Its value lies in dependencies, evidence and boundaries. Keep those visible, and the system can adapt without quietly changing the goal or treating every obstacle as permission to improvise.

Sources and further reading

Anthropic: Building effective agents. Historical conceptual description of adaptive agent processes; published December 2024.

OpenAI Agents SDK: Running agents. Execution-loop documentation; checked October 2026.

OpenAI Agents SDK: Human-in-the-loop. Approval-gated pause and resume; checked October 2026.