Agent overview — the three axes of Tool · Actor · Intent

In D.Hub, an agent is a workflow that takes natural-language input and runs a full cycle of tool calls + decisions automatically. This lesson pins down the three axes of an agent and the 5-step one-cycle flow.

The three axes

1. Tool

A tool represents read · search actions. A call that fetches external data without side effects.

Examples:

• get_enriched_order(order_id) — Fetch one row from a dataset
• search_refund_policy(query) — Embedding search over a knowledge resource (RAG)
• query_tactical_zone(zone_name) — Look up tactical zone metadata

A tool is safe to call multiple times. Same input, same output — deterministic reads.

2. Actor

An actor represents write · action operations. Calls that change external state.

Examples:

• issue_refund(order_id, amount) — Refund API call, an actual financial transaction
• send_rejection_email(customer_id, reason) — Email send
• log_map_event(user_id, command, output) — Audit log write
• capture_review_decision(reviewer_id, decision) — An actor that takes a human reviewer's decision (HITL)

Actor calls can't be undone. An email fired can't be recalled, and a refund API creates a completed transaction. Almost every agent safety pattern concentrates on gates immediately before the actor call.

3. Intent classification

Intent classification is an LLM call that classifies the input itself to route it to the right flow. Before calling any tool or actor, it maps the user's input to one of the allowed categories.

Example (the classify_intent tool from Turn natural-language commands into safe chart control and audit history):

• UI_CONTROL — Screen control intent → allowed
• DATA_QUERY — Data query intent → blocked
• SYSTEM_CONFIG — System config change intent → blocked

Intent classification is default deny (Lesson 5).

The 5-step one-cycle flow

The three axes combine into a one-cycle flow:

sequenceDiagram
    accTitle: Tool calls and the human-approval boundary
    accDescr: A user request is classified, enriched by tools, reasoned over by the LLM, reviewed by a person when needed, and only then sent to an actor.
    actor User
    participant Agent as AI agent
    participant Tool
    actor Reviewer as Human reviewer
    participant Action as Actor
    User->>Agent: Submit request
    Agent->>Agent: Classify intent
    Agent->>Tool: Gather context
    Tool-->>Agent: Return evidence
    Agent-->>Reviewer: Recommend action
    alt Reviewer approves
        Reviewer->>Action: Approve execution
        Action-->>User: Return action result
    else Reviewer rejects
        Reviewer-->>User: Explain rejection
    end

1. User input → intent classification — Is this input within our agent's scope? One classification LLM call.
2. Tool calls × 1–N — Gather context. Dataset fetches · RAG search · external API queries.
3. LLM reasoning — With the gathered context, produce a recommendation or response. Citation grounding in the body.
4. (HITL) human review — A human actor accepts or overrides the recommendation. Only for flows with high safety risk.
5. Actor calls × 1–N — Apply the decision to external state. Fire the refund · send the email · transmit the coordinate JSON.

Each step holds a separated responsibility — so that an LLM malfunction in one step can be caught at the next step's gate.

Reference scenarios — three agent patterns

The 6 lessons of this Path take turns referencing three scenario patterns.

If you have the three scenario files (ZIP) on hand, each lesson's example works immediately. Download and import follows the Import and tour a complete hands-on scenario pattern.

What you should be able to do after this lesson

• The three-axis division — Tool · Actor · Intent classification
• The 5-step one-cycle flow and each step's responsibility
• The first safety rule — actor calls cannot be undone

Next lesson

Define one tool with an input/output schema contract.