Pause an agent for approval with KV Store
Run a tool-calling agent loop in a function, pause it in KV Store before an action a person approves, and record every task event in SQL Database.
You run a tool-calling agent loop in a function, store a task in KV Store when the model asks for an action a person must approve, resume it on the decision, and write every task event to SQL Database, with the Azion CLI and a function’s code.
Prerequisites
- An application and a workload that serve your domain, with Application Accelerator turned on, which the Run Function behavior requires. To create them, refer to Applications quickstart.
- KV Store and SQL Database enabled on the account. Both are in Preview and not enabled by default, so request access through Technical Support.
- The
agent-stateKV Store namespace. To create it, refer to Create the namespace. - The
agent-historydatabase, with a table created by the statementCREATE TABLE task_events (task_id TEXT NOT NULL, event TEXT NOT NULL, steps INTEGER NOT NULL, at TEXT NOT NULL);. To create the database and send the statement, refer to Create a database using the API and Create a table using the API. - A personal token with the Edit SQL Database permission, for the history writes. To create one, refer to Personal tokens.
- The Azion CLI, installed and authorized, to store the environment variables.
- A third-party provider whose chat endpoint accepts the OpenAI chat completions format with tool definitions, with its URL, the name of a model that supports tool calling, and an API key.
The examples give the agent two tools over an order service at https://api.example.com/v1: get_order, which reads GET /orders/{id}, and refund_order, which calls POST /orders/{id}/refunds and needs a person’s approval. They use www.example.com for the domain. Replace them with your values.
Store the values the function reads
The provider key, the backend token, the approver secret, and the personal token stay out of the code, as environment variables.
To store the values the function reads, run these commands with the Azion CLI. A key that contains key, token, or secret is stored as a secret by default:
The account holds the seven variables the agent function reads with Azion.env.get().
The Build AI agents use case uses the values of this example.
Create the agent function
The function runs the loop on /api/agent/tasks and resumes it on /api/agent/approve. A tool in APPROVAL_TOOLS never runs from the loop: the function stores the task under task:<task-id> in agent-state for one day, and runs the tool only when a person approves it.
Create a function named ops-agent with this code. The provider call sends the key as Authorization: Bearer; change that header to the one your provider requires:
To create the function and its instance, follow Functions quickstart with the name ops-agent, and name the instance ops-agent, with no Args.
The application carries an ops-agent instance that runs a task until the model answers, a refund needs approval, or six steps pass.
The Build AI agents use case uses the values of this example.
Run the function on the agent’s paths
One rule runs the instance on both agent paths. Both take POST, and the function answers any other method with 405.
Create a Request Phase rule as Create the rule for the path and the method describes, with these values: the name agent - tasks and approvals, one criteria group with ${uri} starts with /api/agent/ in place of the guide’s path and method groups, and the Run Function behavior selecting the ops-agent instance.
A task sent to /api/agent/tasks runs the agent, and every start, pause, decision, and end lands in task_events. A new rule takes a few minutes to propagate.
Confirm a task pauses and resumes once
To send a task that needs only get_order:
The response carries "status":"completed", an answer that states the order’s status, and steps of 2 or more: one step that calls get_order, and one that answers.
Send {"task":"Refund order <order-id>, the customer received a damaged item."} to the same path. The response carries "status":"awaiting_approval", the task_id, and an action naming refund_order with the order ID, and the order service has received no refund.
To approve the refund, send the task_id from that response with the approver secret:
The response carries "status":"completed", and the order service has received one refund. The same request sent again answers 404 with no pending action for this task, and a request without the Authorization header answers 401.
To read the events of the refund task, send the statement SELECT event, steps FROM task_events WHERE task_id = '<task-id>' ORDER BY rowid; to the SQL Database API, as Query rows shows. The results rows list started, awaiting_approval, approved, and completed, in that order.
The agent pauses before the refund, runs it once after the approval, and records each event in task_events.
These checks confirm the Build AI agents use case.