CHAPTER 43 AI AGENTS, PLANNING, TOOL CALLING, TASK STATE, PERMISSION BOUNDARIES, HUMAN APPROVAL & SAFE AUTONOMOUS EXECUTION 43.1 Introduction The previous chapter established the AI orchestration lay
By Coderz Club · 2026-09-04 · Tags: ai, go
CHAPTER 43 AI AGENTS, PLANNING, TOOL CALLING, TASK STATE, PERMISSION BOUNDARIES, HUMAN APPROVAL & SAFE AUTONOMOUS EXECUTION
43.1 Introduction The previous chapter established the AI orchestration layer for controlled model inference. The next architectural step is the AI agent layer. A conventional AI request normally follows: User → Model → Response An agentic system can instead follow: Goal → Plan → Retrieve → Reason → Propose Action → Verify → Execute → Observe → Continue This additional capability creates substantial engineering and security requirements. An AI agent should therefore not be designed as: “Give the model access to everything and let it decide what to do.” Instead, the application should define explicit boundaries around: what the agent can see, what the agent can remember, what tools it can call, what parameters it can provide, what actions require approval, what actions are prohibited, how long a task may run, how many steps are allowed, and how every action is recorded. The fundamental architecture is: User Goal ↓ Agent Orchestrator ↓ Planner ↓ Task State ↓ Tool Authorization ↓ Tool Proposal ↓ Validation ↓ Approval Policy ↓ Tool Execution ↓ Observation ↓ Verifier ↓ Next Step / Completion 43.2 What Is an AI Agent? For this architecture, an AI agent is a system in which a model can participate in a multi-step workflow by: interpreting a goal, creating or selecting a plan, requesting information, proposing tool operations, receiving tool results, evaluating those results, and continuing until the task reaches a defined completion condition. The model itself is not the entire agent. A safer definition is: Agent = Model + Orchestrator + State + Tools + Policies + Verification This distinction is extremely important. The application remains responsible for authorization and execution. 43.3 Agent Versus Chatbot A chatbot might perform: Question ↓ Answer An agent might perform: Goal ↓ Plan ↓ Retrieve Information ↓ Analyze ↓ Prepare Action ↓ Request Approval ↓ Execute ↓ Verify The second architecture requires significantly more controls. 43.4 Agent Architecture A complete agent subsystem can be organized as: AGENT SYSTEM │ ┌───────────┴───────────┐ ▼ ▼ Agent Session Agent Policy │ │ ▼ ▼ Planner Permissions │ │ ▼ │ Task State │ │ │ ▼ │ Tool Selection ◄──────────────┘ │ ▼ Tool Proposal │ ▼ Validation │ ▼ Approval Check │ ▼ Tool Execution │ ▼ Observation │ ▼ Verifier │ └──────────→ Next Step 43.5 Agent Session Every agent workflow should have an explicit session. Conceptual structure: AgentSession ├── id ├── userId ├── projectId ├── taskId ├── agentType ├── status ├── createdAt └── updatedAt Possible statuses include: CREATED RUNNING WAITING_APPROVAL PAUSED COMPLETED FAILED CANCELLED EXPIRED This makes long-running workflows manageable. 43.6 Agent Task A task represents the objective the agent is trying to accomplish. Example: Task: "Summarize the uploaded research documents and prepare a structured report." The task should have: taskId goal userId projectId status priority createdAt deadline The goal should be treated as data associated with the task, not as an unrestricted instruction to the entire application. 43.7 Task State Machine Agent tasks should use explicit state transitions. Example: CREATED ↓ PLANNING ↓ EXECUTING ↓ WAITING_APPROVAL ↓ EXECUTING ↓ VERIFYING ↓ COMPLETED Failure can transition to: FAILED Cancellation can transition to: CANCELLED Invalid state transitions should be rejected by the application. 43.8 Why Explicit State Matters Without persistent state, an agent can lose track of: what it already did, which tool was used, what result was returned, which step is awaiting approval, whether an operation already succeeded. Persistent state allows the workflow to resume safely. 43.9 Agent Steps A task can contain multiple steps. For example: Task │ ├── Step 1: Find relevant documents ├── Step 2: Extract evidence ├── Step 3: Compare findings ├── Step 4: Draft report └── Step 5: Request review Each step should have its own status. Recommended states: PENDING RUNNING WAITING COMPLETED FAILED SKIPPED CANCELLED 43.10 Planning The planner converts a goal into an executable sequence. Conceptually: Goal ↓ Planner ↓ Plan ↓ Step 1 Step 2 Step 3 ... However, plans should not automatically authorize actions. A plan is a proposal. The application must independently enforce permissions. 43.11 Plan Validation Before execution, the system should validate the plan. Checks may include: permitted tools, project scope, data access, maximum steps, action sensitivity, approval requirements, resource limits. Conceptually: Generated Plan ↓ Policy Validator ↓ Allowed? ┌───┴───┐ Yes No ↓ ↓ Execute Reject/Revise 43.12 Bounded Planning Agents should operate within explicit limits. Example limits: maxSteps maxRuntime maxToolCalls maxRetrievalResults maxTokens maxConcurrentActions This prevents an accidental loop from running indefinitely. A bounded agent is easier to debug and safer to operate. 43.13 Tool Reg
43.1 Introduction The previous chapter established the AI orchestration layer for controlled model inference. The next architectural step is the AI agent layer. A conventional AI request normally follows: User → Model → Response An agentic system can instead follow: Goal → Plan → Retrieve → Reason → Propose Action → Verify → Execute → Observe → Continue This additional capability creates substantial engineering and security requirements. An AI agent should therefore not be designed as: “Give the model access to everything and let it decide what to do.” Instead, the application should define explicit boundaries around: what the agent can see, what the agent can remember, what tools it can call, what parameters it can provide, what actions require approval, what actions are prohibited, how long a task may run, how many steps are allowed, and how every action is recorded. The fundamental architecture is: User Goal ↓ Agent Orchestrator ↓ Planner ↓ Task State ↓ Tool Authorization ↓ Tool Proposal ↓ Validation ↓ Approval Policy ↓ Tool Execution ↓ Observation ↓ Verifier ↓ Next Step / Completion 43.2 What Is an AI Agent? For this architecture, an AI agent is a system in which a model can participate in a multi-step workflow by: interpreting a goal, creating or selecting a plan, requesting information, proposing tool operations, receiving tool results, evaluating those results, and continuing until the task reaches a defined completion condition. The model itself is not the entire agent. A safer definition is: Agent = Model + Orchestrator + State + Tools + Policies + Verification This distinction is extremely important. The application remains responsible for authorization and execution. 43.3 Agent Versus Chatbot A chatbot might perform: Question ↓ Answer An agent might perform: Goal ↓ Plan ↓ Retrieve Information ↓ Analyze ↓ Prepare Action ↓ Request Approval ↓ Execute ↓ Verify The second architecture requires significantly more controls. 43.4 Agent Architecture A complete agent subsystem can be organized as: AGENT SYSTEM │ ┌───────────┴───────────┐ ▼ ▼ Agent Session Agent Policy │ │ ▼ ▼ Planner Permissions │ │ ▼ │ Task State │ │ │ ▼ │ Tool Selection ◄──────────────┘ │ ▼ Tool Proposal │ ▼ Validation │ ▼ Approval Check │ ▼ Tool Execution │ ▼ Observation │ ▼ Verifier │ └──────────→ Next Step 43.5 Agent Session Every agent workflow should have an explicit session. Conceptual structure: AgentSession ├── id ├── userId ├── projectId ├── taskId ├── agentType ├── status ├── createdAt └── updatedAt Possible statuses include: CREATED RUNNING WAITING_APPROVAL PAUSED COMPLETED FAILED CANCELLED EXPIRED This makes long-running workflows manageable. 43.6 Agent Task A task represents the objective the agent is trying to accomplish. Example: Task: "Summarize the uploaded research documents and prepare a structured report." The task should have: taskId goal userId projectId status priority createdAt deadline The goal should be treated as data associated with the task, not as an unrestricted instruction to the entire application. 43.7 Task State Machine Agent tasks should use explicit state transitions. Example: CREATED ↓ PLANNING ↓ EXECUTING ↓ WAITING_APPROVAL ↓ EXECUTING ↓ VERIFYING ↓ COMPLETED Failure can transition to: FAILED Cancellation can transition to: CANCELLED Invalid state transitions should be rejected by the application. 43.8 Why Explicit State Matters Without persistent state, an agent can lose track of: what it already did, which tool was used, what result was returned, which step is awaiting approval, whether an operation already succeeded. Persistent state allows the workflow to resume safely. 43.9 Agent Steps A task can contain multiple steps. For example: Task │ ├── Step 1: Find relevant documents ├── Step 2: Extract evidence ├── Step 3: Compare findings ├── Step 4: Draft report └── Step 5: Request review Each step should have its own status. Recommended states: PENDING RUNNING WAITING COMPLETED FAILED SKIPPED CANCELLED 43.10 Planning The planner converts a goal into an executable sequence. Conceptually: Goal ↓ Planner ↓ Plan ↓ Step 1 Step 2 Step 3 ... However, plans should not automatically authorize actions. A plan is a proposal. The application must independently enforce permissions. 43.11 Plan Validation Before execution, the system should validate the plan. Checks may include: permitted tools, project scope, data access, maximum steps, action sensitivity, approval requirements, resource limits. Conceptually: Generated Plan ↓ Policy Validator ↓ Allowed? ┌───┴───┐ Yes No ↓ ↓ Execute Reject/Revise 43.12 Bounded Planning Agents should operate within explicit limits. Example limits: maxSteps maxRuntime maxToolCalls maxRetrievalResults maxTokens maxConcurrentActions This prevents an accidental loop from running indefinitely. A bounded agent is easier to debug and safer to operate. 43.13 Tool Reg