---
title: "Agentic AI engineering"
description: "A personal demonstration of agent control: scripted plans, typed tools, approval, and verification on fictional data. ORBIT does not call a model."
canonical: "https://www.ayushrai.site/pow/agentic-ai/"
last-updated: "2026-10-19"
---

# Agentic AI engineering

Source: https://www.ayushrai.site/pow/agentic-ai/
Markdown: https://www.ayushrai.site/pow/agentic-ai.md

A personal demonstration of agent control: scripted plans, typed tools, approval, and verification on fictional data. ORBIT does not call a model.

Personal engineering demonstration. The workbench is a deterministic simulation. It is not a deployed autonomous agent platform, and it does not call a model.

I engineer AI systems that combine reasoning, tools, state, and verification to execute multi-step tasks with control.

## Thesis

An agent is more than an LLM call. On this page the plan is scripted so the control flow can be inspected. A sentence that says a task was created is not completion. Completion is a row the store can read back.

- Task interpretation — name the outcome before choosing a tool.
- Planning and bounded execution — a plan is a proposal with a step budget, not a proof of completion.
- Tool selection — this page uses a fixed plan so the controller, not a model, decides the next call.
- State management — the run keeps the task, the step, the evidence, and the approval on one record.
- Evidence collection — claims cite fixture rows.
- Output validation — tool results have to match the contract the registry published.
- Error handling — a timeout can be retried once; a bad argument cannot.
- Human approval — a write waits. Approval is not the write.
- Result verification — the task counts only when the store contains the row.
- Observability — the trace shows inputs, outputs, and why a run stopped. Durations are not measured here.

## Loop

Request → Plan → Validate plan → Select permitted tool → Execute → Validate result → Update state → Continue or stop → Verify final outcome

## Tasks

- Investigate a deteriorating account: Explain why Northwind Analytical looks unhealthy and, if the evidence supports it, store one internal follow-up.
- Summarize unresolved support issues: List the open support records and leave the store unchanged.
- Prepare an internal escalation: Draft an internal note and propose one escalation task.
- Find missing information before acting: Decide whether a renewal follow-up can be recommended.

## Tools

- `get_account` (read, account:read): Read the fictional account record.
- `get_recent_events` (read, events:read): Read recent fixture events for the account.
- `list_support_tickets` (read, tickets:read): List support records, optionally filtered by status.
- `calculate_health_score` (read, health:read): Compute the fixture health score from stored rows.
- `search_evidence` (read, evidence:read): Find fixture passages that contain the query.
- `create_internal_task` (write, tasks:write): Store an internal follow-up task. Requires controller approval.
- `draft_notification` (draft, drafts:write): Store an internal draft. This demonstration does not send it.
- `verify_task_created` (read, tasks:read): Read the store and report whether the task row exists.

## Failure scenarios

- Tool timeout: The read fails once, the controller retries once, and the second attempt returns the fixture events.
- Invalid tool arguments: The call is rejected before the handler. The handler counter stays at zero.
- Conflicting evidence: The run stops as uncertain and does not pick a winning invoice status.
- Duplicate action request: The second write returns the original task. The store still has one row.
- Rejected approval: The proposed task is not stored. Later steps are skipped.
- Failed verification: The adapter reports success, the store has no row, and the outcome is unverified.
- Maximum execution budget: The run stops after two executed steps and names the work it did not do.
- Untrusted tool output: The planted instruction is quoted as ticket text. No send tool runs, and no task is written.

## Roadmap

- Phase 1 — Website and deterministic simulation (implemented). This page. Scripted tasks, local fixtures, and a controller in the browser.
- Phase 2 — Typed tool interfaces and an execution state machine (partial). The types and the machine exist in this frontend. They are not a server runtime.
- Phase 3 — Persistent state and audit records (not_started). The audit list lives in component state and disappears on refresh.
- Phase 4 — Real model provider integration (not_started). No provider is called. modelCalls is 0.
- Phase 5 — Controlled tool execution and authorization (not_started). The approval flag is local. There is no identity, tenancy, or service credential.
- Phase 6 — Retry policies, idempotency, and verification (partial). The simulation shows one retry, one idempotency key, and a store read. They are not production policies.
- Phase 7 — Agent evaluation and observability (partial). Metrics are computed from these scenarios and labeled illustrative. There is no trace backend.
- Phase 8 — Deployment hardening and security review (not_started). This frontend is not a security boundary.

## Related work

- Revenue Intelligence Engine. A synthetic GTM pipeline: deterministic scoring, a research step with a fallback, and a human approval queue before export. It does not send outbound mail or write to a live CRM. That approval-before-effect pattern is the one ORBIT copies. It is not an autonomous agent.
- MedVoice. Speech proposes an order line. Catalog matching, tax, and invoice posting are deterministic, and an ERP failure is not reported as a sale. That is the same split between a proposal and a verified effect. It is not an agent orchestrator, and it has no public demo URL.
- AGENYRA. A public site and waitlist for structured product data. Search over structured fields is not the same thing as placing a product inside an agent. The public repository does not contain an agent runtime.
- RevenueRoles. A job-discovery pipeline: collect postings, normalize them, classify by the work described, and keep a link back to the original page. Useful pipeline and verification habits. Not an agent that applies to jobs.
- SpiderWeb. Turns a LinkedIn data export into local people, companies, and conversation records. Counts are counts of imported rows. It runs locally and is not an agent.
- OpenAI-RLHF. An archive of coding-evaluation tasks and A/B completion pairs. The repository's own summary says it does not contain an RLHF, PPO, or DPO trainer. It shows evaluation artifacts, not an agent loop.
- This website's agent interfaces. Markdown twins, lexical search, and a read-only MCP server over the public records. That is a surface an agent can call. It is not an agent that browses and acts.
- adaptive-rag. The public repository describes a LangGraph routing demo. Commit history is mostly Dhruv Singhal's (12 commits to 1 on this account). I am not describing it as my agent system, and this site does not claim a production RAG deployment.

An agent is only as useful as the work it can reliably complete—and the evidence that it completed it.

_Unverified award metrics are omitted. Wording matches the public site._