Building a Single-Agent Workflow
Build a single-agent system to create callback tasks while enforcing strict approval protocols and permission checks. Configure the agent to retrieve support ticket details, evaluate task requirements, and propose callback task creation without performing unauthorized actions. Incorporate a human approval step to review and authorize proposed actions before execution. Maintain separate records for proposals, approval decisions, and task statuses to ensure accountability and prevent expired approvals from authorizing actions. Implement secure pause-and-resume mechanisms that revalidate permissions, approval validity, and task details before resuming execution. Verify execution results against an authoritative ledger, preserve evidence of approvals and system activities, and maintain a complete audit trail. Apply these controls to support secure task execution, consistent state management, operational integrity, and traceable agent workflows.
At 12:01 UTC, a Northstar reviewer approved one action: create an internal callback task for ticket NS-209 at 13:00 UTC, ahead of the ticket’s 14:00 deadline. The approval was valid until 12:10. The worker holding the request restarted, came back at 12:11, found approved=True in storage, and created the task. The callback time was still fine. The permission had expired.
“Your agent can write to our support system. What stops it from creating a task nobody approved?” is the interview question this lesson answers. We build one end-to-end Northstar workflow: scoped tools, versioned instructions, a typed result, a human approval step that survives a worker restart, and a traced run. The action is small on purpose. The customer stays uncalled and the ticket stays open.
What may the agent do, and what does the application supply?
The agent can read NS-209, request the callback task, and report what actually happened. Calling the customer, closing the ticket, changing billing, moving the deadline, and switching organizations aren’t in its tool surface. It gets two function tools: get_ticket(ticket_id), which returns NS-209 only after checking the authenticated organization and the operator’s entitlement, and create_callback_task(ticket_id, callback_at), which creates one support-queue record through a guarded adapter.
Two records keep the request apart from the permission. A proposal is the action the agent asked for, waiting for a decision. A decision is the reviewer’s approval or rejection, and the application grants permission only after checking it against the exact proposal and current conditions such as an expiration time.
The model chooses only the ticket ID and the callback timestamp. The application builds everything else as trusted context: organization, operator, task scope, clock, remaining budget, and adapters. It never accepts organization IDs, reviewer identities, approval flags, queries, or admin commands from the model. Before preparing a proposal, it checks ticket ownership and entitlement, requires a timezone on the timestamp, normalizes it to UTC, and checks that it falls between now and the deadline.
A local SQLite adapter stands in for Northstar’s queue, so writes are real and inspectable. A database uniqueness constraint on the proposal ID prevents duplicate callback rows for that proposal. The callback, receipt, and proposal status commit in one transaction. This provides a local duplicate-write boundary, not a guarantee for external services. The task is capped at four model turns and six tool reads and writes in total. Both counters persist across pauses and restarts; an on_llm_start hook reserves model budget before each request.
The agent uses gpt-6-luna, which the model catalog describes as the efficient option for focused, high-volume tasks with function-tool support. The ...