The Agent Development Lifecycle: From Workflow Selection to Production Control
The Agent Development Lifecycle: From Workflow Selection to Production Control
The Agent Development Lifecycle: From Workflow Selection to Production Control
Executive Summary
AI agents are moving from experimental demos into enterprise workflows. They can retrieve information, reason across context, call tools, hand off tasks, update systems, request approval, and complete multi-step work. That makes them more powerful than basic chatbots — and much harder to build safely.
The enterprise problem is no longer “Can we build an AI agent?” The better question is:
Can we build an AI agent that solves the right workflow, uses the right data, calls the right tools, stays inside autonomy limits, passes evaluation, and remains controllable in production?
That is why Etheon uses the Agent Development Lifecycle, or ADLC, as a structured framework for designing, building, testing, launching, governing, and maintaining enterprise AI agents.
The need for a lifecycle is urgent. McKinsey’s 2025 global AI survey found that 88% of organizations reported regular AI use in at least one business function, while 23% were already scaling agentic AI somewhere in the enterprise and another 39% were experimenting with agents [1]. Gartner has warned that more than 40% of agentic AI projects may be canceled by the end of 2027 because of escalating costs, unclear business value, or inadequate risk controls [2]. Stanford HAI’s 2026 AI Index reports that AI agents improved sharply on OSWorld, moving from 12% to roughly 66% task success, but still failed about one in three structured benchmark attempts [3].
Those three facts define the 2026 agent reality: adoption is accelerating, failure risk is material, and capability is improving but not reliable enough for uncontrolled autonomy.
The ADLC is designed to close that gap. It gives enterprise buyers and AI teams a practical path from workflow selection to production control.
What Is the Agent Development Lifecycle?
The Agent Development Lifecycle is a structured lifecycle for developing AI agents from business problem to production system. It adapts product development, software engineering, AI evaluation, security architecture, and governance practices to the specific risks and capabilities of agentic AI.
A traditional software lifecycle manages requirements, design, implementation, testing, deployment, and maintenance. An AI agent lifecycle must manage more:
- Workflow selection
- Agent suitability
- Autonomy level
- Data access
- Retrieval and grounding
- Tool design
- Agent identity
- Human approval
- Prompt injection risk
- Tool abuse risk
- Data leakage risk
- Evaluation and traces
- Observability
- Model lifecycle
- Production monitoring
- Continuous improvement
OpenAI describes agents as systems that can use tools, hand off work, rely on guardrails, and support multi-step workflows [4]. OpenAI’s Agents SDK documentation also emphasizes orchestration loops, handoffs, sessions, tracing, guardrails, and resumable approval flows [5]. Microsoft Foundry’s agent evaluation documentation includes task completion, task adherence, intent resolution, tool call accuracy, tool selection, tool input accuracy, tool output utilization, and tool call success [7]. These sources all point to the same conclusion: agents are systems, not prompts.
The ADLC gives that system a lifecycle.
Why Enterprises Need an ADLC
Enterprise agents fail when organizations treat them like advanced chatbots.
A chatbot answers.
An agent acts.
A production agent must be controlled.
The risks are different. A chatbot may hallucinate a response. An agent may retrieve sensitive data, call the wrong API, update a record, trigger a workflow, send a message, or continue taking steps after the user expected it to stop.
OWASP’s 2026 Top 10 for Agentic Applications identifies risks specific to autonomous and agentic systems that plan, act, and make decisions across complex workflows [11]. OWASP’s 2025 Top 10 for LLM and generative AI applications also includes prompt injection, sensitive information disclosure, vector and embedding weaknesses, and excessive agency [12]. These risks are lifecycle risks. They cannot be solved with a final security scan.
The ADLC exists because agentic systems require repeatable gates:
- Should this workflow use an agent at all?
- What autonomy level is justified?
- What data can the agent access?
- What tools can it call?
- What requires human approval?
- How will the agent be evaluated?
- How will prompt injection and data leakage be tested?
- How will production behavior be monitored?
- How can the agent be paused or rolled back?
Without a lifecycle, agent projects become brittle, expensive, and hard to govern. With a lifecycle, every agent moves through controlled stages.
Research Audit: What the Current Agent Landscape Shows
The current market shows both opportunity and caution.
McKinsey’s 2025 survey shows that agentic AI is already moving beyond discussion: 23% of organizations are scaling at least one agentic AI system and 39% are experimenting [1]. Gartner’s warning on cancellations shows that many projects will fail unless value, cost, and risk are managed from the beginning [2]. Stanford HAI’s benchmark data shows agents are becoming much more capable, but not yet dependable enough for broad autonomy without controls [3].
The technical ecosystem is also maturing. Amazon Bedrock Agents can orchestrate interactions between foundation models, data sources, software applications, and user conversations, and can call APIs and invoke knowledge bases [9]. Google’s Agent Development Kit is described as an open-source framework for building, debugging, and deploying reliable AI agents at enterprise scale [10]. OpenAI’s Agents SDK supports tool loops, handoffs, tracing, sessions, guardrails, and approval flows [5]. Microsoft Foundry provides agent-specific evaluators for task completion and tool-call behavior [7].
The market has frameworks, tools, and platforms. What enterprises still need is a disciplined development lifecycle.
That is the role of ADLC.
The Etheon ADLC Framework
Etheon’s Agent Development Lifecycle has 12 stages:
1. Workflow selection
2. Agent suitability assessment
3. Risk tier and autonomy design
4. Agent charter and job definition
5. Data and knowledge readiness
6. Tool and action design
7. Agent architecture and orchestration
8. Human oversight and control design
9. Prototype and sandbox validation
10. Evaluation, red teaming, and production gates
11. Controlled pilot and production launch
12. Production monitoring, maintenance, and lifecycle control
Each stage has a clear purpose, decision output, and production gate.
Stage 1: Workflow Selection
The first ADLC stage is choosing the right workflow.
This is the most important decision in the lifecycle. Many agent projects fail because they begin with “we need an agent” instead of “we have a workflow worth agentic automation.”
A strong workflow candidate has:
- High business value
- Repeatable work
- Clear inputs and outputs
- Accessible data
- Defined systems
- Measurable baseline
- Human review path
- Manageable risk
- Business owner
- Production KPI
Good candidates include support triage, invoice exception handling, procurement intake, IT incident enrichment, compliance evidence collection, CRM hygiene, customer onboarding, sales account preparation, and internal service routing.
Weak candidates include workflows with unclear ownership, poor data, high legal exposure, irreversible actions, unclear success metrics, or decisions that require nuanced human judgment without strong review.
The first ADLC question is:
Would an agent materially improve this workflow, or would a rule, dashboard, integration, assistant, or process redesign solve it better?
Gartner’s cancellation forecast is a reminder that agent projects need clear business value and risk controls before investment expands [2].
Stage output: workflow candidate brief with owner, baseline, KPI, risk level, data sources, and expected value.
Production gate: no workflow owner, no agent.
Stage 2: Agent Suitability Assessment
Not every AI system should be an agent. Some use cases need a copilot. Some need secure RAG. Some need predictive analytics. Some need deterministic rules.
An agent is suitable when the workflow requires multi-step execution, tool use, state, branching, or coordination across systems. OpenAI describes agents as appropriate when systems need to accomplish tasks on behalf of users using models, tools, instructions, and guardrails [4]. Amazon Bedrock Agents similarly describes agents as systems that can orchestrate interactions between foundation models, data sources, software applications, and user conversations [9].
Use an agent when the workflow needs:
- Planning across steps
- Retrieval plus action
- API calls
- Tool selection
- Workflow state
- Conditional routing
- Human approval
- Multi-system coordination
- Exception handling
Do not use an agent when:
- The task is a simple Q&A
- The logic is deterministic
- The output only needs drafting
- The workflow has no clear goal
- Data permissions are unresolved
- Actions are high-risk and unbounded
- The agent would have little volume or ROI
Stage output: agent suitability decision: agent, assistant, RAG, rules, automation, analytics, or do not build.
Production gate: agent architecture must be justified by workflow complexity, not novelty.
Stage 3: Risk Tier and Autonomy Design
The third ADLC stage defines risk and autonomy.
Autonomy should be treated as a design variable, not a default. A practical autonomy model:
1. Autonomy level: Level 0
Agent capability: Answer only
Human role: Human acts
2. Autonomy level: Level 1
Agent capability: Draft
Human role: Human edits and sends
3. Autonomy level: Level 2
Agent capability: Recommend
Human role: Human approves or rejects
4. Autonomy level: Level 3
Agent capability: Act with approval
Human role: Agent prepares action; human confirms
5. Autonomy level: Level 4
Agent capability: Limited autonomy
Human role: Agent executes low-risk actions within strict limits
6. Autonomy level: Level 5
Agent capability: Broad autonomy
Human role: Agent manages complex workflows with minimal supervision
Most enterprise agents should begin at Levels 1–3. Level 4 requires strong monitoring and low-risk, reversible actions. Level 5 should be rare and requires mature governance, containment, and evaluation.
Stanford HAI’s 2026 AI Index shows why: agents have improved significantly on real computer tasks, but still fail roughly one in three structured benchmark attempts [3]. That is not a reason to avoid agents. It is a reason to design autonomy carefully.
Risk tiering should consider:
- Data sensitivity
- Customer impact
- Financial impact
- Legal impact
- Employee impact
- Safety impact
- Action reversibility
- Tool risk
- Regulatory exposure
- Human review availability
NIST’s AI Risk Management Framework is designed to help organizations manage AI risks across the lifecycle [13], and ISO/IEC 42001 provides requirements and guidance for establishing, maintaining, and continually improving an AI management system [14]. These are governance foundations for autonomy design.
Stage output: risk tier, autonomy level, approval thresholds, and prohibited actions.
Production gate: autonomy cannot exceed the organization’s ability to evaluate, monitor, and contain the agent.
Stage 4: Agent Charter and Job Definition
An enterprise agent needs a job description.
The agent charter should define:
- Agent name
- Business purpose
- Workflow scope
- User group
- Allowed tasks
- Prohibited tasks
- Data sources
- Tools
- Human approval points
- Escalation logic
- Success metrics
- Failure conditions
- Risk owner
- Support owner
A good agent charter reads like a controlled operating instruction, not a vague prompt.
Example:
“The billing triage agent reviews incoming Tier 2 billing tickets, retrieves approved policy and account context, classifies urgency, drafts an internal recommendation, and routes refund exceptions to a human manager. It may not approve refunds, modify contracts, update billing records, or send customer-facing responses without approval.”
This charter becomes the basis for prompts, tools, guardrails, evaluation, monitoring, and governance.
Stage output: agent charter and operating boundary.
Production gate: no agent should be built without a written job definition and prohibited-action list.
Stage 5: Data and Knowledge Readiness
Agents need data, but data creates risk.
The ADLC requires a data readiness review before agent development. This includes structured data, unstructured documents, APIs, knowledge bases, CRM records, ERP records, tickets, logs, policies, and customer or employee data.
Review:
- Source authority
- Data owner
- Data classification
- Permission model
- Data freshness
- Retention rules
- Deletion propagation
- Sensitive data
- Legal or regulatory constraints
- Retrieval strategy
- Evaluation examples
CISA and partner agencies released AI data security guidance emphasizing data provenance, integrity, secure storage, and protection against maliciously modified or poisoned data [17]. This matters because agents can act on retrieved or structured data. Bad data can produce bad action.
For RAG-enabled agents, also define:
- Approved sources
- Chunking strategy
- Metadata
- Embeddings
- Vector index security
- Source ranking
- Citation requirements
- Permission-aware retrieval
Freshness checks
Amazon Bedrock Knowledge Bases positions retrieval as a way to ground generative AI applications and agentic systems in enterprise data [18].
Stage output: data readiness assessment and approved source list.
Production gate: the agent cannot access unclassified, ownerless, stale, or permission-unclear data.
Stage 6: Tool and Action Design
Tools are what make an agent operational. They are also what make the agent risky.
A tool can retrieve a record, call an API, create a ticket, update a CRM field, run a query, send a notification, generate a report, or trigger a workflow. Amazon Bedrock Agents uses action groups with API schemas and functions to define API operations an agent can call [9]. OpenAI’s Agents SDK manages recurring orchestration such as repeated tool calls, branching, handoffs, sessions, tracing, guardrails, and approval flows [5].
The tool design stage should define:
- Tool purpose
- Allowed users
- Agent identity
- Input schema
- Output schema
- Permission requirements
- Rate limits
- Validation rules
- Approval requirements
- Error handling
- Logging
- Rollback options
- Prohibited parameters
- Test cases
Tool access should be separated into:
- Read tools
- Draft tools
- Recommendation tools
- Write tools with approval
- Limited autonomous write tools
- Prohibited tools
OWASP’s agentic risk guidance highlights risks such as tool misuse, identity and privilege abuse, supply chain compromise, code execution, memory poisoning, and rogue agents [11]. Tool design is where those risks become controls.
Stage output: tool registry and tool policy.
Production gate: no tool may be added without schema validation, permissions, logging, and risk classification.
Stage 7: Agent Architecture and Orchestration
The seventh ADLC stage designs the agent architecture.
Architecture decisions include:
- Single agent or multi-agent
- Model selection
- Prompt and instruction structure
- Retrieval strategy
- Tool orchestration
- State management
- Memory design
- Handoff logic
- Approval pauses
- Guardrails
- Observability
- Deployment environment
- Cost controls
Google’s Agent Development Kit is described as a framework for building, debugging, and deploying reliable AI agents at enterprise scale [10]. Google’s ADK announcement also emphasizes precise control over agent behavior, tool ecosystems, debugging, and evaluation [19]. OpenAI’s Agents SDK similarly supports orchestration loops, handoffs, sessions, tracing, guardrails, and approval flows [5].
The architecture should also include model strategy. A frontier model may handle planning. A smaller model may handle classification. A deterministic rules engine may validate policy. A RAG system may supply evidence. A human approval system may control high-risk actions.
Architecture is where the agent becomes a system, not a prompt.
Stage output: agent architecture diagram, model strategy, orchestration plan, and architecture decision records.
Production gate: architecture must show how data, tools, identity, evaluation, approvals, and monitoring work together.
Stage 8: Human Oversight and Control Design
Human oversight is not an afterthought. It is a workflow.
Define:
- Which actions require approval
- Which outputs require review
- Who reviews them
- What evidence is shown
- Whether the reviewer can edit
- Whether the reviewer can reject
- Whether the reviewer can escalate
- Whether override reasons are logged
- What happens if no reviewer is available
- How reviewer feedback improves the agent
Human review is especially important for customer-facing communication, finance actions, legal interpretation, HR workflows, security remediation, external sends, payment actions, and irreversible updates.
Approval interfaces should show:
- Agent recommendation
- Supporting evidence
- Retrieved sources
- Proposed tool call
- Tool parameters
- Expected side effect
- Risk reason
- Confidence or uncertainty where appropriate
- Approve / reject / edit / escalate options
OpenAI’s agent guide emphasizes guardrails and human intervention as part of safe agent deployment [4]. Human oversight is one of the most important guardrails.
Stage output: human review workflow and approval rules.
Production gate: high-risk actions cannot be automated without meaningful human oversight and audit logs.
Stage 9: Prototype and Sandbox Validation
The prototype should test the riskiest assumption, not simulate the whole future product.
Prototype questions may include:
- Can the agent retrieve the right sources?
- Can it call the right tool?
- Can it handle missing data?
- Can it refuse prohibited requests?
- Can it route high-risk cases?
- Can it produce useful drafts?
- Can it meet latency requirements?
- Can it avoid sensitive data exposure?
- Can it maintain workflow state?
- Can it work at expected cost?
The prototype should run in a sandbox with limited data and limited tools. It should not have production write access. It should use realistic examples and adversarial cases, not only happy-path demos.
Stage output: prototype report with feasibility results, risks, and revised scope.
Production gate: prototypes should not be promoted unless they test real workflow constraints.
Stage 10: Evaluation, Red Teaming, and Production Gates
Agent evaluation must test more than final answers.
OpenAI’s agent evaluation guidance recommends starting with traces because a trace captures the end-to-end record of model calls, tool calls, guardrails, and handoffs [6]. Microsoft Foundry agent evaluators include task completion, task adherence, intent resolution, tool call accuracy, tool selection, tool input accuracy, tool output utilization, and tool call success [7]. Microsoft Foundry observability also includes quality, RAG, safety, and agent-specific metrics [8].
An agent evaluation stack should include:
1. Evaluation layer: Business outcome
What to test KPI improvement, cost per task, workflow impact
2. Evaluation layer: Final output
What to test Accuracy, relevance, groundedness, refusal accuracy
3. Evaluation layer: Retrieval
What to test Source relevance, citation accuracy, permission enforcement
4. Evaluation layer: Trajectory
What to test Steps, sequence, handoffs, escalations
5. Evaluation layer: Tool use
What to test Tool selection, parameters, outputs, side effects
6. Evaluation layer: Autonomy
What to test Level of independence, escalation, failure recovery
7. Evaluation layer: Security
What to test Prompt injection, data leakage, tool abuse, excessive agency
8. Evaluation layer: Operations
What to test Latency, cost, reliability, observability
Red teaming should test:
- Direct prompt injection
- Indirect prompt injection
- Malicious documents
- Malicious tool outputs
- Unauthorized retrieval
- Tool misuse
- Agent loops
- Sensitive data leakage
- Memory poisoning
- Role-based access failure
- Cost exhaustion
Stage output: evaluation report, red-team report, and production gate decision.
Production gate: no production launch without trace evaluation, tool-call evaluation, security tests, and business KPI criteria.
Stage 11: Controlled Pilot and Production Launch
The pilot tests the agent with real users in controlled scope.
A strong pilot includes:
- One workflow
- One user group
- Limited tools
- Limited autonomy
- Human approval
- Monitoring
- Feedback capture
- Cost tracking
- Incident path
- Baseline comparison
- Scale criteria
During the pilot, measure:
- Task completion rate
- Human acceptance rate
- Override rate
- Escalation accuracy
- Tool-call accuracy
- Data leakage incidents
- Prompt injection attempts
- Latency
- Cost per task
- User satisfaction
- KPI movement
The pilot should end with a decision:
- Scale
- Improve
- Hold
- Reduce autonomy
- Redesign
- Stop
Production launch should include:
- Support process
- Monitoring dashboard
- Access review
- Incident response
- Rollback plan
- User training
- Admin documentation
- Release notes
- Governance evidence
Stage output: pilot report and production readiness decision.
Production gate: scale only after value and control are proven.
Stage 12: Production Monitoring, Maintenance, and Lifecycle Control
Agents change after launch. Data changes. Tools change. Models change. Workflows change. User behavior changes. Costs change. Security risks change.
Production control is the final ADLC stage and the beginning of ongoing operations.
Monitor:
- Task completion
- Tool calls
- Tool failures
- Human approvals
- Overrides
- Retrieval quality
- Refusals
- Prompt injection attempts
- Data leakage signals
- Latency
- Cost
- Model version
- Prompt version
- User feedback
- Incidents
- Business KPI impact
Maintain:
- Prompts
- Tools
- Data sources
- RAG indexes
- Evaluation datasets
- Model routing
- Access controls
- Security tests
- User training
- Documentation
- Incident playbooks
NIST’s AI RMF and ISO/IEC 42001 both emphasize lifecycle risk management and continual improvement for AI systems [13][14]. Agentic systems require exactly that.
Stage output: operating model, monitoring dashboard, review cadence, and lifecycle plan.
Production gate: an agent without monitoring and maintenance ownership should not remain in production.
ADLC Production Control Model
The ADLC uses six control gates before production scale.
1. Control gate: Workflow gate
Required evidence: Business owner, baseline, KPI, workflow fit
2. Control gate: Autonomy gate
Required evidence: Risk tier, autonomy level, prohibited actions
3. Control gate: Data gate
Required evidence: Approved sources, permissions, classification, freshness
4. Control gate: Tool gate
Required evidence: Tool registry, schemas, permissions, approval rules
5. Control gate: Evaluation gate
Required evidence: Trace evals, tool evals, red-team tests, safety metrics
6. Control gate: Production gate
Required evidence: Monitoring, support, incident response, rollback, owner
These gates are designed to prevent common agent failures: unclear value, excessive autonomy, unsafe tools, data leakage, weak evaluation, and no post-launch owner.
ADLC Maturity Levels
Enterprise teams can measure maturity across five levels.
Level 1: Experimental Agents
Agents are built in playgrounds or prototypes. Tools are limited. Evaluation is informal. Business value is unclear.
Level 2: Controlled Pilots
Agents have scoped workflows, limited data, basic evaluation, and human review. Production controls are incomplete.
Level 3: Production Agents
Agents have owners, monitoring, evaluation, tool policies, human approval, and incident response.
Level 4: Governed Agent Platform
The enterprise has shared agent architecture, tool registry, model routing, secure retrieval, evaluation libraries, and governance workflows.
Level 5: Adaptive Agent Operations
Agents are continuously evaluated, monitored, improved, and governed across workflows, with controlled autonomy and lifecycle management.
Most enterprises should aim for Level 3 before expanding agents across departments.
Common ADLC Mistakes
The first mistake is starting with an agent instead of a workflow.
The second mistake is giving agents tools before defining autonomy.
The third mistake is connecting agents to data before permission review.
The fourth mistake is evaluating only final answers.
The fifth mistake is treating human oversight as a policy rather than a workflow.
The sixth mistake is skipping red-team testing.
The seventh mistake is launching without observability.
The eighth mistake is failing to define ownership after launch.
The ninth mistake is increasing autonomy before measuring reliability.
The tenth mistake is not knowing when to stop.
The ADLC exists to prevent these mistakes.
The Etheon Recommendation
The future of enterprise AI agents will not be determined by who can build the most agents. It will be determined by who can build agents that are useful, safe, evaluated, governed, and controllable in production.
For Etheon, the rule is direct:
Do not develop an AI agent without an Agent Development Lifecycle.
An enterprise-ready ADLC should move from workflow selection to agent suitability, risk tiering, data readiness, tool design, architecture, human oversight, prototype validation, evaluation, controlled pilot, production launch, and lifecycle control.
The agent is not the product.
The controlled workflow is the product.
The lifecycle is what makes the workflow dependable.
The organizations that win with agentic AI will not grant autonomy first and add control later. They will design control first, prove reliability, and expand autonomy only when the evidence supports it.
That is the purpose of the Agent Development Lifecycle: to turn agentic AI from a demo into a production operating capability.
References
[1] McKinsey, “The State of AI: Global Survey 2025.” https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai
[2] Gartner, “Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027.” https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027
[3] Stanford HAI, “The 2026 AI Index Report.” https://hai.stanford.edu/ai-index/2026-ai-index-report
[4] OpenAI, “A Practical Guide to Building AI Agents.” https://openai.com/business/guides-and-resources/a-practical-guide-to-building-ai-agents/
[5] OpenAI, “Agents SDK.” https://developers.openai.com/api/docs/guides/agents
[6] OpenAI, “Evaluate Agent Workflows.” https://developers.openai.com/api/docs/guides/agent-evals
[7] Microsoft Foundry, “Agent Evaluators for Generative AI.” https://learn.microsoft.com/en-us/azure/foundry/concepts/evaluation-evaluators/agent-evaluators
[8] Microsoft Foundry, “Observability in Generative AI.” https://learn.microsoft.com/en-us/azure/foundry/concepts/observability
[9] AWS, “How Amazon Bedrock Agents Works.” https://docs.aws.amazon.com/bedrock/latest/userguide/agents-how.html
[10] Google Cloud, “Agent Development Kit.” https://docs.cloud.google.com/gemini-enterprise-agent-platform/build/adk
[11] OWASP GenAI Security Project, “OWASP Top 10 for Agentic Applications 2026.” https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/
[12] OWASP, “Top 10 for Large Language Model Applications.” https://genai.owasp.org/resource/agentic-ai-threats-and-mitigations/
[13] NIST, “AI Risk Management Framework.” https://www.nist.gov/itl/ai-risk-management-framework
[14] ISO, “ISO/IEC 42001:2023 — AI Management Systems.” https://www.iso.org/standard/42001
[15] NIST AI RMF Playbook. https://airc.nist.gov/airmf-resources/playbook/
[16] AWS, “Amazon Bedrock Knowledge Bases.” https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base.html
[17] CISA, “New Best Practices Guide for Securing AI Data Released.” https://hai.stanford.edu/ai-index/2026-ai-index-report/responsible-ai
[18] AWS, “Automate Tasks in Your Application Using AI Agents.” https://docs.aws.amazon.com/bedrock/latest/userguide/agents.html
[19] Google Developers Blog, “Making It Easy to Build Multi-Agent Applications.” https://developers.googleblog.com/en/agent-development-kit-easy-to-build-multi-agent-applications/