Standards and workflow landscape
- Created: 2026-08-25T00:19:28+02:00
- Status: seed; landscape survey, not a validated standard
- Method: web research summarized from the linked standards and project sources
There is a useful standards stack for engineering agentic AI systems, but no single universal “agentic engineering standard” covers the full problem. Governance and lifecycle standards are relatively mature; agent-specific interoperability, identity, memory, and communication standards are still developing. Current IETF and IEEE work reflects that ongoing standardization. (IETF)
Core standards and frameworks
Organizational governance — ISO/IEC 42001:2023
This defines an AI management system: policies, responsibilities, risk processes, performance monitoring, audits, and continual improvement. It applies to agentic systems, although it is not specifically an “AI-agent standard.” (ISO)
Risk management — ISO/IEC 23894:2023
Use this to integrate AI-specific risk management into development, deployment, operation, and organizational processes. (ISO)
Engineering lifecycle — ISO/IEC 5338:2023
This is probably the closest formal foundation for an agentic engineering lifecycle. It defines AI-system lifecycle processes and extends conventional software and systems-engineering lifecycle standards with AI-specific activities. (ISO)
Impact assessment — ISO/IEC 42005:2025
Use this to evaluate the effects of an AI system on people and society, particularly before releasing agents that make consequential decisions or act on users’ behalf. (ISO)
Operational risk framework — NIST AI RMF
The NIST AI Risk Management Framework organizes work around four functions: Govern, Map, Measure, and Manage. Its Generative AI Profile and Playbook provide practical activities and documentation guidance. It is voluntary rather than a certification standard. (NIST)
Agent-specific protocols and guidance
MCP — agent-to-tool and agent-to-data integration
The Model Context Protocol provides a common way for an agent application to discover and use tools, resources, prompts, and external data. It reduces the need to create a separate proprietary connector for every model–tool combination. MCP is an open protocol, not an ISO management standard. (Model Context Protocol)
A2A — agent-to-agent communication
The Agent2Agent protocol addresses discovery, communication, task management, and artifact exchange between independently built agents. MCP and A2A are complementary: MCP primarily connects an agent to tools and data, while A2A connects agents to other agents. (A2A Protocol)
OWASP Agentic Security
The OWASP Top 10 for Agentic Applications 2026 covers agent-specific risks such as goal hijacking, tool misuse, identity and privilege abuse, memory poisoning, insecure inter-agent communication, cascading failures, and rogue-agent behavior. OWASP also publishes a securing-agentic-applications guide. (OWASP Gen AI Security Project)
OpenTelemetry GenAI conventions
These provide emerging common fields for tracing model calls, tool calls, results, token usage, latency, and agent operations. They are useful for observability, although parts of the agent-specific conventions continue to evolve. (OpenTelemetry)
A practical agentic engineering workflow
Define purpose
↓
Set autonomy and resource boundaries
↓
Assess impact and threats
↓
Design tools, permissions and data contracts
↓
Build the guarded agent loop
↓
Evaluate and red-team
↓
Deploy gradually
↓
Monitor, investigate and improve
1. Define the agent contract
Document:
- The exact objective and owner.
- What the agent may and may not do.
- Allowed tools, data sources, recipients, environments, and domains.
- Maximum token, time, monetary, and API-call budgets.
- Actions requiring human approval.
- Success, failure, escalation, and termination conditions.
Treat this as an agent charter, not merely a system prompt.
2. Perform risk and impact assessments
Map the use case through NIST’s Govern–Map–Measure–Manage functions and, for more formal programs, ISO/IEC 23894 and ISO/IEC 42005.
Threat-model at least:
- Prompt and goal injection.
- Excessive or inherited permissions.
- Malicious tool output.
- Memory poisoning.
- Credential leakage.
- Unauthorized communications.
- Cascading multi-agent actions.
- Irreversible actions and failed compensation.
3. Design resource access explicitly
Every tool should have:
- A strict input and output schema.
- A narrowly scoped identity.
- Least-privilege permissions.
- Timeouts, quotas, and rate limits.
- Idempotency protection for retryable actions.
- Clear read-versus-write separation.
- A defined approval policy.
- Sanitized errors that do not expose secrets.
Use MCP where interchangeable tool or data integration is valuable. Use A2A only when independently deployed agents genuinely need to collaborate; do not create a multi-agent architecture when a simpler deterministic workflow will work.
4. Build a guarded execution loop
A reliable loop is:
Observe → propose plan → validate → authorize → act → verify → record
The model should propose an action, but a deterministic policy layer should decide whether that action is permitted. Raw model output should not directly execute privileged operations.
For high-impact actions—sending external messages, spending money, changing permissions, deleting records, publishing content, or making regulated decisions—insert a human or policy approval gate.
5. Evaluate the complete workflow
Test more than response quality. Measure:
- End-to-end task completion.
- Correct tool selection and parameters.
- Unauthorized-action rate.
- Recovery from unavailable or malicious tools.
- Resistance to prompt injection.
- Memory correctness and contamination.
- Reproducibility across model versions.
- Latency, token consumption, and total cost.
- Human-escalation quality.
- Rollback and compensation success.
Maintain both normal “golden task” tests and adversarial tests. Run them whenever prompts, models, tools, permissions, memory logic, or orchestration code change.
6. Deploy progressively
Use sandbox environments first, followed by shadow operation, limited users, canary deployment, and gradual expansion. Set circuit breakers for abnormal cost, excessive iteration counts, repeated failures, unexpected domains, and privilege violations.
7. Operate it as a production system
For every run, record the agent version, model version, instruction version, user and agent identity, policy decision, tool calls, sanitized arguments and results, approvals, generated artifacts, cost, and final outcome.
Keep an incident-response and rollback procedure. Agent prompts, tool definitions, permissions, policies, and evaluation sets should all be version-controlled.
Minimum documentation package
A team implementing agents should maintain these artifacts:
- Agent charter and autonomy classification
- Architecture and data-flow diagram
- Tool registry and permission matrix
- Risk, impact, and threat assessment
- Evaluation suite and release thresholds
- Trace and audit-log specification
- Human-approval policy
- Incident, rollback, and agent-disable runbook
For a small engineering team, a good starting stack is NIST AI RMF + OWASP Agentic Top 10 + MCP where needed + OpenTelemetry tracing. For enterprise or regulated deployment, add ISO/IEC 42001, 23894, 5338, and 42005, with A2A only where cross-agent interoperability is a real requirement. For EU deployments, also map the system separately to the EU AI Act because legislation and engineering standards serve different purposes. (commission.europa.eu)