Chapter 14 of 15

A Reusable Agentic Product Framework

Eight layers every agentic product needs, independent of the specific model or stack. I wanted this section to explain not only what changed, but why the previous approach stopped being enough once the product met real operating conditions.

  • Input
  • Reasoning
  • Tools
  • Execution
  • Feedback
  • Persistence
  • Control
  • Commercial outcome

Input

  • What forms of input does the product accept (text, image, URL, code, video)? I would answer this with the actual current system behaviour, not the intended design on a diagram.
  • How is ambiguous or malicious input handled before it reaches the model? I would answer this with the actual current system behaviour, not the intended design on a diagram.

Reasoning

  • Is this a single call or a multi-turn loop? I would answer this with the actual current system behaviour, not the intended design on a diagram.
  • Is the orchestration coupled to one model provider? I would answer this with the actual current system behaviour, not the intended design on a diagram.

Tools

  • What can the model actually do, concretely (files, commands, network)? I would answer this with the actual current system behaviour, not the intended design on a diagram.
  • What is the policy boundary around each tool? I would answer this with the actual current system behaviour, not the intended design on a diagram.

Execution

  • Where does generated or agent-driven work actually run? I would answer this with the actual current system behaviour, not the intended design on a diagram.
  • What isolation and resource limits apply to that execution? I would answer this with the actual current system behaviour, not the intended design on a diagram.

Feedback

  • How does the system know an action failed? I would answer this with the actual current system behaviour, not the intended design on a diagram.
  • Is failure fed back to the agent in a structured, actionable form? I would answer this with the actual current system behaviour, not the intended design on a diagram.

Persistence

  • What is the durable object the user expects to keep? I would answer this with the actual current system behaviour, not the intended design on a diagram.
  • Does history, diffing, and rollback exist for it? I would answer this with the actual current system behaviour, not the intended design on a diagram.

Control

  • Where can a human inspect, pause, or reverse what the agent did? I would answer this with the actual current system behaviour, not the intended design on a diagram.
  • Are customer-facing actions gated by human approval where it matters? I would answer this with the actual current system behaviour, not the intended design on a diagram.

Commercial outcome

  • What business process does this feed into once generation is done? I would answer this with the actual current system behaviour, not the intended design on a diagram.
  • How is usage, cost, and value measured per customer? I would answer this with the actual current system behaviour, not the intended design on a diagram.