Runtime AI agents

The SR Method can be used for any software project, even without embedded AI agents.

The SR Agent Method is an optional extension for designing AI agents integrated in business applications.

Positioning

The SR Agent Method is not a framework. It does not replace LangChain, LangGraph, PydanticAI, CrewAI, LlamaIndex or agent SDKs.

It first defines the application contract of the agent, then lets the developer choose the appropriate execution tool.

Since SR 3.2.0, the method is intentionally provider-, framework-, domain-, and UI-agnostic. It can be used for a classification micro-agent, a workflow agent, a delegation agent, a UI mini-agent, or a fuller backend agent.

The 6 building blocks

1. Bounded product action: what the agent may do, and what it does not do.
2. Stable internal representation: pivot language, domain schema, or application object used between the agent and the product.
3. Runtime contract: available inputs, forbidden data, expected outputs, possible refusals, validations, and traces.
4. Prompt contract: role, task, hard rules, out of scope, and output format.
5. Message builder: application code that injects the right variables from real product state.
6. Controlled runtime: tools, actions, routing, fallback, parser, strict validation, and non-sensitive logs.

Agent shapes

The SR Agent Method distinguishes the agent shape before choosing a technology:

Minimal runtime AI agent contract

The contract tells Codex how to design the agent:

agent_key:
label:
runtime_shape:
purpose:
bounded_product_action:
business_function_key:
stable_internal_representation:
model_provider:
model:
temperature:
execution_mode:
system_prompt:
user_prompt_template:
message_builder_inputs:
input_schema:
output_schema:
input_model:
output_model:
json_schema_source:
output_validation_mode:
invalid_output_policy:
validation_error_trace:
typed_output_tests:
authorized_tools:
authorized_actions:
sql_context_bindings:
nexus_context_bindings:
required_runtime_skills:
routing_policy:
fallback_policy:
ui_placement:
test_cases:
risk_notes:
human_validation_required:
validation_status:
is_active:

Pydantic Output Contract

Since SR pack 3.0.3, JSON produced by an LLM is not considered reliable application data.

Target flow:

Pydantic model or equivalent
-> JSON schema exposed to the LLM
-> LLM JSON answer
-> strict runtime validation
-> accepted application object or controlled error

An output JSON schema guides the model, but is not enough. Only the backend can decide whether the output is acceptable.

Mandatory rules

• No free SQL generated and executed by the LLM.
• SQL queries must be controlled backend-side.
• Outputs consumed by the application must be structured and validated.
• The system prompt is not enough: the runtime contract and message builder must be written in code.
• Tools read or transform; state-changing actions must be separated, authorized, and validated.
• Dangerous, unknown, or out-of-contract fields must be stripped or rejected by the parser.
• Critical actions require user validation.
• An agent must not be activated without validation: explicit validation_status and is_active=false before approval.
• In Python, validation must rely on Pydantic.
• In another stack, an equivalent typed validator is mandatory.
• Invalid output must never trigger a critical action.
• Automatically repaired output must remain blocked for human validation if it can produce a sensitive business effect.

Prompt to frame agents

Use docs/codex/prompts/15_define_runtime_agents.md. Do not code.

Read AI_AGENT_RUNTIME_METHOD.md, domain docs, relevant schemas, routes and models.

I want to create an AI agent whose function will be: [expected description]

For each agent: agent_key, purpose, prompts, input_schema, output_schema, SQL/Nexus bindings, runtime skills, UI, tests, risks, human validation, validation_status and is_active=false.

For each candidate agent, also explain how LLM JSON output will be validated backend-side. In Python, propose input and output Pydantic models. In another stack, propose the equivalent typed validator.

For each agent, also define the bounded product action, stable internal representation, runtime contract, message builder, tools, actions, routing/fallback policy, and required traces.