AI DEVELOPMENT / DEDICATED BUILD

Agentic AI

Place a model inside a bounded observe-plan-act loop so it can select tools, maintain state, recover from errors, and request approval for consequential actions.

What it is

Place a model inside a bounded observe-plan-act loop so it can select tools, maintain state, recover from errors, and request approval for consequential actions.

This page separates the concept, implementation path, interactive experiment, evaluation criteria, failure modes, and sources so the topic can be studied without relying on a summary tile.

Core concepts

State records what the agent currently knows about the task and environment.
Planning selects a next action or decomposes work into smaller steps.
Tools connect model reasoning to deterministic code or external systems.
Observation feeds tool results back into the loop.
Approval gates separate suggestions from actions that affect people, systems, money, data, or external communication.

Architecture / workflow

Receive a task and convert it into an explicit contract: goal, constraints, tools, budget, and stop conditions.
Observe current state and available evidence.
Choose one bounded action and validate its parameters.
Execute through an authorized tool, capture the result, and update state.
Stop, recover, or request human approval when confidence, authority, cost, or safety boundaries are exceeded.

Technical foundations

A useful abstraction is a state machine over (state, observation, action, result).
Idempotent tools and replayable traces make recovery safer.
Budgets can bound steps, time, tokens, external requests, or financial cost.
Permission checks should be enforced outside the language model whenever possible.

Evaluation checklist

Task completion rate on reproducible scenarios.
Tool-call validity and parameter accuracy.
Recovery success after injected failures.
Rate of unnecessary or unauthorized actions.
Trace completeness: can another person reconstruct why each action occurred?

Failure modes and limits

Long action chains compound small errors.
A model may call the right tool with the wrong parameter.
Untrusted tool output can influence later reasoning.
Hidden state makes failures hard to reproduce.
Over-broad permissions convert reasoning mistakes into real-world side effects.

Practical build path

Start with one deterministic tool and a tiny state machine.
Add structured observations, logging, and explicit stop conditions.
Add more tools only with per-tool authorization and validation.
Introduce approval gates, budgets, replay, rollback, and adversarial testing before external actions.

Primary / authoritative references

Search the Learn library for related lessons →

AUTHORED STUDY COMPANION / 3.2

Execute a typed tool and recover after a failure

Prerequisites. Function contracts, transactions, capability checks and idempotency.

A tool-using system needs an execution contract independent of the language used to request the action. The companion accepts one schema: record_count with an integer count, a named idempotency key and an explicit capability flag. Unknown tools, malformed arguments and ungranted capabilities fail before an effect is accepted.

The effect and request digest are committed together in an in-memory SQLite transaction. A simulated crash then occurs before the workflow's next checkpoint. Replaying the same request finds the committed digest and returns the existing result instead of duplicating the effect. Reusing the key for different arguments fails. This demonstrates the required state transitions inside one process; the database is not durable across program termination.

Exactly-once behavior cannot be assumed for arbitrary remote tools. A remote payment or message service must support its own idempotency or a suitable reconciliation protocol. The local fixture deliberately performs no network call, shell command or external account change. Attempts are bounded to two in the scripted scenario; a production worker would persist its cumulative attempt budget separately from a rollbackable workflow checkpoint.

Execute a typed tool and recover after a failure — model structure
Element	Model	Interpretation
Validate	Known tool + integer arguments	Reject malformed requests
Authorize	Explicit record_count capability	Gate the effect
Commit / replay	Key + payload digest + effect	Avoid duplicate accepted effects

Predict, run, compare

Default execution logs effect.committed, checkpoint.restored, effect.replayed. The final effect count is one. Removing the capability must raise PermissionError; replaying a changed count must raise ValueError.

Download executable notebooks and source Inspect source ↗

Open agent.ipynb in the package. Run cells in order, compare with the reference, then change the stated input. Restart the kernel to reset.

Computed reference result — local CPU fixture

{
  "state": {
    "next": "done",
    "attempts": 2,
    "budget": 2
  },
  "result": 3,
  "effect_count": 1,
  "events": [
    "effect.committed",
    "checkpoint.restored",
    "effect.replayed"
  ]
}

This is the recorded result of the included code under the package environment. It is not a live service or device measurement.

Extend the experiment

Add a second tool with a distinct schema and capability. Test invalid arguments, denied permission, same-payload retry and conflicting-payload retry before adding any external side effect.

Check your reasoning: What makes a replay safe in this fixture?

The request sounds reasonable — Natural-language plausibility is not an execution guarantee.
A matching key and payload digest in the effect transaction — Correct. The stored digest distinguishes a retry from a conflicting new request.
Calling the tool twice quickly — Timing does not prevent duplicate effects.

This is an explained self-check, not a certification of mastery.

Claim-specific sources

Reviewed 2026-10-02: this worked example and its explicit assumptions. Source links and notebook results do not establish production or hardware validation.