How to Enforce Tool Execution Order in an Agent (AG-UI)

[tschokokuki]

Dear community,

I am designing a simple agent with two tools:

• get_work_item
• update_work_item

The get_work_item tool retrieves a work item (for example a Kanban card containing title, description, state, etc.) and:

• adds the item to the model context
• stores it in the application state for UI rendering

My goal is to enforce the following behavior:

• When a user sends a request such as: “Rewrite the description of work item 1234”
• the agent must first call get_work_item(1234) before it is allowed to call update_work_item(1234).

I want to guarantee this ordering because otherwise:

• the work item may never be loaded into the UI state
• the agent could generate an update purely from the user prompt without reading the current content first

I am aware that prompting the model with instructions like: “Always call get_work_item before update_work_item” is not a reliable enforcement mechanism.

What is the recommended architectural approach to enforce this dependency?

The only option I currently see is: a sequential tool call via workflow (then add as sub agent)

However, this seems way overengineered to me for such a simple scenario.
Is there a simpler solution for this pattern? I feel like I must be missing something.

Thanks in advance for your advice.

[moonbox3]

Hi @tschokokuki, thanks for the question. You are right on both counts: prompting is not an enforcement mechanism, and a workflow is overengineered for a pairwise tool dependency like this. The framework has a lighter primitive for exactly this case.

The approach I would recommend is progressive tool exposure. Do not register update_work_item on the agent at all. Instead, have get_work_item add it to the run once a fetch succeeds. A tool can declare a FunctionInvocationContext parameter (it is injected by the framework and never shown to the model) and mutate the live tool list:

from agent_framework import ChatAgent, FunctionInvocationContext, tool


@tool
def update_work_item(work_item_id: str, description: str) -> str:
    ...


@tool
def get_work_item(work_item_id: str, ctx: FunctionInvocationContext) -> str:
    item = fetch_work_item(work_item_id)  # your data access + UI state update
    ctx.add_tools(update_work_item)  # only now does the model gain access to it
    return item.model_dump_json()


agent = ChatAgent(
    chat_client=client,
    tools=[get_work_item],  # update_work_item deliberately not registered
)

This is a hard guarantee, not a hint. Until get_work_item runs, update_work_item is not in the request sent to the model, so it cannot be called early. It also fits your AG-UI setup well: the tool list resets on each run, so every new user turn starts gated again and the agent must re-read the current item before updating it, which is exactly the behavior you described wanting. One note: add_tools / remove_tools are currently experimental (you will see an ExperimentalWarning on first use) and the API may still get refinements.

If you also want to enforce that the update targets the same item that was fetched, or guard against parallel tool calls within a single model iteration, you can layer a function middleware on top. Setting context.result without calling call_next() skips execution and returns your message to the model as the tool result, so the model self-corrects:

from agent_framework import FunctionInvocationContext, FunctionMiddleware


class RequireFetchBeforeUpdate(FunctionMiddleware):
    def __init__(self) -> None:
        self.fetched_ids: set[str] = set()  # scope per session in a real app

    async def process(self, context: FunctionInvocationContext, call_next) -> None:
        if (
            context.function.name == "update_work_item"
            and context.arguments.work_item_id not in self.fetched_ids
        ):
            context.result = (
                "Rejected: call get_work_item for this work item first, "
                "then retry the update with the current content."
            )
            return
        await call_next()
        if context.function.name == "get_work_item":
            self.fetched_ids.add(context.arguments.work_item_id)

And if you additionally want to guarantee the very first model action is the fetch, tool_choice supports forcing a named function via {"mode": "required", "required_function_name": "get_work_item"}. The function-calling loop resets it after the first iteration so it will not loop.

So in short: hide the dependent tool until its precondition is met, block at invocation time for argument-level checks, and force a first call if needed. Workflows are only warranted when you need genuine multi-step orchestration across agents, not for a simple ordering constraint like this one.

[tschokokuki]

Thank you, @moonbox3 ! This is the answer I was looking for.

[ishita-0301]

I wouldn't rely on prompting for this. I'd enforce it in the tool layer itself.

For example, have "update_work_item" check whether "get_work_item" has already been called for that ID in the current session. If not, either reject the call or automatically fetch the item first. That way the invariant is guaranteed regardless of what the model decides to do.

This is also why I like runtime guardrail approaches in general. Projects like FailproofAI take a similar philosophy of enforcing safe execution instead of hoping the model follows instructions: https://github.com/FailproofAI/failproofai.

[tschokokuki]

Thanks for the input! The runtime guardrail approach sounds valid, will look into it.

[ishita-0301]

When the agent tries to call update_work_item(1234), FailproofAI can inspect the current execution state and check whether get_work_item(1234) has already been called in the same session. If the prerequisite hasn't been satisfied, it can block the action, redirect the agent to fetch the work item first, or ask it to retry with the correct sequence.
The key idea is that the policy is enforced at execution time, not left to the model's memory or prompt following. So even if the LLM forgets the instruction or takes an unexpected path, the system guarantees that get_work_item → update_work_item ordering is preserved. This makes the workflow deterministic and prevents incorrect updates based only on the user's prompt.

I believe this will be a great addition to your agent and will also open a new door to learning for you. Happy to discuss how you're progressing with your project on this thread itself!