Agentic AI is a system that pursues a goal over multiple steps by reasoning about what it needs, calling tools to get it, reading the results, and deciding whether to continue. Generative AI produces an answer from a prompt; an agent runs a loop until the objective is met. That loop is the entire difference, and everything hard about agents follows from it.
1. Generative versus agentic, precisely
| Generative | Agentic | |
|---|---|---|
| Interaction | One prompt, one response | A goal, then many steps |
| External state | None | Reads and often writes it |
| Failure mode | A wrong answer | A wrong action |
| What it needs | A good prompt | Good tools, and limits it cannot talk past |
The third row is the one that matters commercially. A wrong answer is embarrassing and recoverable. A wrong action \u2014 a posted journal entry, a sent email, a refund \u2014 is not, and the controls an agent needs follow from that asymmetry rather than from anything about the model.
2. The ReAct loop
ReAct interleaves reasoning and acting. The model produces a Thought about what it needs, an Action that calls a tool, and then reads the Observation the tool returns. It repeats until the goal is met or a limit stops it.
THOUGHT Need the PO total before I can compare anything.
ACTION erp.getPurchaseOrder({ id: "8042" })
OBSERVE { total: 48210.00, currency: "AED", vendor: "Gulf Steel" }
THOUGHT Now find settlements against this vendor in the window.
ACTION bank.findSettlements({ vendor: "Gulf Steel", window: "30d" })
OBSERVE [{ ref: "TT-91180", amount: 48210.00 }]
THOUGHT Amounts tie. Variance is zero — record and stop.
ACTION erp.postReconciliation({ po: "8042", variance: 0 })
OBSERVE OK · variance 0.00 · no exception raisedEverything an agent framework provides is scaffolding around those three steps: state between iterations, retry on malformed output, a limit on how many times the loop may run, and a record of what happened.
3. Framework comparison, honestly
| Framework | Shape | Best when |
|---|---|---|
| LangGraph | Explicit graph of nodes and edges | The flow is known and you want it enforced rather than hoped for |
| AutoGen | Conversing agents | A task genuinely decomposes into roles that need to argue |
| CrewAI | Role and task abstraction | Fast assembly of a multi-role workflow |
| Client-side (Dart, Swift, Kotlin) | Loop runs on the device | Latency, per-call cost or data residency are the binding constraint |
Framework choice gets far more attention than it deserves. The variable that actually determines whether an agent works is tool design: a typed signature, a narrow scope, a schema the model cannot misread, and an error the model can recover from. A well-specified tool makes a mediocre model useful. A vague one makes the best available model unreliable.
4. Why client-side is worth the engineering
Running the loop on the device removes three things at once: the orchestration server you would otherwise operate, the per-call cost that scales with usage, and the data-residency conversation, because sensitive fields never leave the handset.
The trade is that model calls still need network unless you are running a small model locally, and that state has to survive a dropped connection. Checkpointing solves the second, which is why it is a first-class concern in any client-side framework worth using.
5. What changes when an agent touches a ledger
Most agent demos summarise a document. Enterprise agents post to accounts that get audited, and that changes what the framework has to guarantee.
- Deterministic tool contracts. The model chooses which tool to call, never what a call means.
- Idempotent writes. A retry after a timeout must not double-post. This is the difference between a demo and something near a general ledger.
- Append-only audit trail. Every thought, call and observation recorded, so an auditor can reconstruct why a posting happened.
- A human gate on value. Agents draft and reconcile. Anything that moves money stops for a person.
Putting those limits in the system prompt is asking a probabilistic model to enforce its own constraints. They belong in a control plane between the model and the tool, where they cannot be talked out of. For outbound agent actions, gateways like SadaSend enforce this boundary at the protocol level through Model Context Protocol (MCP) servers, scoped keys, and human-in-the-loop approval queues.