Managing the life cycle of AI agents at scale
InfoWorld ·
There’s a new reality emerging for development teams: existing software delivery practices don’t translate cleanly to agentic AI systems . Practices built around deterministic execution paths and well-defined application behaviors are no longer sufficient when the software itself can make decisions about how to accomplish a task. The main difference is that agents exhibit non-deterministic, context-dependent behavior. In contrast to traditional applications, where behavior is determined by code and configuration, agents can make dynamic decisions about how to tackle a task, which tools to use, and what actions to carry out. Their behavior is influenced by models, prompts, tools, data, memory, and the runtime context. These new requirements now apply to how we design, evaluate, observe, govern, and run software, since conventional software development life cycles were not intended to meet them. This situation creates the need for an agent development life cycle (ADLC). ADLC extends existing software development practices by incorporating agent-specific considerations such as continuous evaluation, agent observability, agent identity, tool access, and governance at every stage of the process, from agent definition and design through development, deployment, and production operation. Let’s look at some key aspects of ADLC and how they address the unique requirements of building and operating agents. Start by defining the agent Before you start writing any code, you must clearly define the problem the agent is supposed to solve, the scope and boundaries of that problem, and the criteria for judging success. For example, a hotel booking agent could help users find appropriate hotels, compare options, and make, modify, or cancel reservations. Its scope should also clearly define what the agent is not responsible for. From this scope, establish measurable success criteria. For instance, the agent should successfully handle 95% of valid booking requests without human intervention and must never confirm a booking without first receiving explicit user approval. This gives the team a clear definition of the agent’s objectives and boundaries before deciding how to build it. Design for agentic behavior First, decide whether the use case really needs an agent; if a deterministic workflow can solve the problem, an agent may add unnecessary complexity. When agentic behavior is needed, decide on the right framework, architecture, and patterns; for instance, whether to use a single agent, one that has a supervisor along with specialized agents, or some other kind of orchestration pattern. You need to determine the tools and data the agent will require to carry out its defined scope; this should cover not only the tools the agent is allowed to use but also the limits on the operations it is permitted to carry out. For instance, a hotel booking agent would need access to tools that check availability and make reservations, but should not be given the authority to alter room prices or provide refunds. The design should also specify how the agent will handle context and memory, and how its behavior will be evaluated. The evaluation criteria and datasets should be defined, together with the acceptable limits for quality, safety, latency, cost, and any other relevant factors. The design decisions form the blueprint for implementation, after which the agent can be developed using the selected framework, with evaluation carried out throughout the development process against the success criteria set in the “define” phase described above. Evaluation goes beyond the final answer Evaluation plays a crucial role in agent development and continues throughout the agent’s life cycle. It can occur during the development phase using reference datasets and can also be carried out continuously in live or production-like environments. Evaluators assess various aspects of the agent’s behavior according to established criteria, using deterministic rules, model-based judgment, or domain-specific logic. Unlike traditional testing, agent evaluation cannot be limited to the final output. Because agents make decisions and take actions during the process, the path taken to reach the outcome is as important as the outcome itself. An agent may achieve the expected outcome while taking an inefficient path or performing actions it is not authorized to perform. Therefore, it is necessary to consider various dimensions such as accuracy, helpfulness, safety, tool use, error recovery, efficiency, reasoning quality, and tone. Different dimensions can be evaluated by different evaluators, which carry out specific checks to assess particular aspects of quality. By using multiple evaluators, you create an overall quality profile that includes both the output and the behavior that led to it. In a robotics use case we worked on at WSO2, the agent was controlling a robot and was tasked with finding a trash bin. This involved moving the robot around, capturing images, and checking those images for a trash bin. The agent eventually found the bin, but received a low path-efficiency rating. The evaluator regarded the repeated rotations and image captures as inefficient, even though these actions were necessary for the agent to understand its physical environment. The problem wasn’t with the agent but with the evaluator; to address this, we developed a custom evaluator that accounted for the environment and constraints, then used it to improve the agent’s behavior. The main takeaway is that it should not be enough to say “it works”; you must establish criteria for good agent behavior in the context of the environment in which the agent operates. Observability for agentic systems To understand how an agent behaves, you need visibility into what happens when it is executed, both during development and after it has been put into use. Traditional observability provides visibility into applications through logs, metrics, and traces. Yet agentic systems introduce new types of interactions and execution patterns that have to be understood; for example, those involving model interactions, tool calls, retrievals, interactions between agents, and the execution paths that the agents follow in order to carry out a task. Current observability foundations, such as distributed tracing, remain highly relevant to agentic systems. The problem is not tracing per se, but the absence of a common set of semantics for describing behavior specific to individual agents. Although traditional tracing is well adapted to depicting services, requests, database calls, and other application operations, concepts like model interactions, tool calls, agent handoffs, and agent execution paths need further semantics. Without common semantics, different agent frameworks will represent the same operations differently. For instance, how a tool invocation is captured will vary by framework, making it difficult to consistently understand agent behavior in a heterogeneous environment. The gap is narrowing as standards like OpenTelemetry develop common semantic conventions for agent-specific interactions. These conventions provide a consistent basis for observability tools to collect, analyze, and visualize agent behavior across frameworks. Enforcing agent boundaries Although observability lets us see what an agent is doing, visibility alone is not sufficient; the boundaries set during the design phase must also be enforced at run time. When agents use enterprise systems via various tools, such as those available through Model Context Protocol (MCP) servers, it is necessary to know which agent is making the request and what actions that agent is permitted to carry out. This, in turn, creates the need for agent identities and roles. Access-control policies can turn the boundaries set up during the design phase into permissions that specify the tools and operations an agent can call. The policies can then be enforced at the control points between the agent and the tools it accesses. The hotel booking agent is designed to search for available rooms and make reservations, but it cannot alter room prices or provide refunds. At run time, these limitations are enforced by permitting the relevant search and booking functions while refusing any requests to change the price or issue a refund. This ensures the boundaries set during the design phase are maintained while the agent operates. Governing agent-LLM interactions You need to govern how agents interact with large language models throughout their life cycle. This includes managing model usage and cost and applying the necessary safety and security policies. Agentic workflows may involve several model calls as the agent plans, uses tools, evaluates results, and iterates to reach an outcome. You need to track model and token usage, set budgets, and enforce limits to keep usage within acceptable levels. You also need to address safety and security. You can apply guardrails to model inputs and outputs to detect or prevent issues such as exposure of personally identifiable information, harmful content, prompt injection, and other policy violations. You can also define which models an agent can access and under what conditions. Together, these mechanisms keep agent-LLM interactions within the security, safety, cost, and operational limits set by the organization. Scaling ADLC across the enterprise As agent adoption grows, applying ADLC capabilities consistently becomes increasingly difficult. Different teams are likely to develop and run agents using a variety of frameworks, models, tools, and environments. As the number of agents and teams increases, maintaining consistency across them becomes harder. Evaluation, observability, identity and access, guardrails, budgets, and runtime policies could be handled with different tools and approaches, leading to fragmentation and redundant effort. This makes it difficult to apply common policies, maintain consistent controls, and gain a unified view of agents across the organization. That’s where an agent control plane proves its value. It provides a standard layer to apply and manage these capabilities consistently across the entire agent portfolio, while still enabling teams to develop agents using the frameworks, models, and tools best suited to their specific use cases. Operationalizing ADLC with an agent control plane An agent control plane provides a common way to apply and manage ADLC capabilities consistently throughout the agent life cycle. Organizations can register each agent, along with its purpose, owner, version, tools, and dependencies, to provide visibility across the agent portfolio. They can integrate evaluation requirements into CI/CD pipelines and use quality, safety, and domain-specific thresholds as gates before promoting agents between environments. At run time, identity and access policies can control which tools and enterprise systems an agent can access. Guardrails, budgets, and usage limits can govern its interactions with LLMs. Traces and metrics provide insight into agent behavior, while online evaluations continuously evaluate whether agents continue to meet expected quality and safety standards. These capabilities provide a consistent way to manage agents without forcing development teams to standardize on a particular agent framework, model, or environment. The life cycle does not end when an agent reaches production. Runtime behavior provides information that teams can use to improve the next version of the agent. When an agent’s behavior changes or falls below expected thresholds, teams can use traces and evaluation results to understand what happened. They can then improve the agent, adjust policies or permissions, update evaluations, and deploy a new version. This creates a continuous life cycle in which teams define, design, evaluate, deploy, observe, and govern agents, with what they learn during operation feeding back into the next iteration. The agent control plane provides the common foundation needed to apply these ADLC capabilities consistently as agent adoption scales across the enterprise. Establishing the foundation early Establishing this common foundation early ensures that agents are managed consistently throughout their life cycle, from design and development through to production, with the necessary security controls and visibility in place. This foundation is much easier to establish early than to retrofit later. As agent adoption grows, maintaining consistent controls becomes harder, especially as agents gain access to more models, tools, and enterprise systems while operating within defined boundaries. Organizations early in their agent journey should establish this common foundation before fragmentation and security risks become harder to manage. For organizations already experiencing inconsistent practices across teams or struggling to maintain control and visibility over agents, these are strong signals that they need an agent control plane. — New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com .
There’s a new reality emerging for development teams: existing software delivery practices don’t translate cleanly to agentic AI systems . Practices built around deterministic execution paths and well-defined application behaviors are no longer sufficient when the software itself can make decisions about how to accomplish a task. The main difference is that agents exhibit non-deterministic, context-dependent behavior. In contrast to traditional applications, where behavior is determined by code and configuration, agents can make dynamic decisions about how to tackle a task, which tools to use, and what actions to carry out. Their behavior is influenced by models, prompts, tools, data, memory, and the runtime context. These new requirements now apply to how we design, evaluate, observe, govern, and run software, since conventional software development life cycles were not intended to meet them. This situation creates the need for an agent development life cycle (ADLC). ADLC extends existing software development practices by incorporating agent-specific considerations such as continuous evaluation, agent observability, agent identity, tool access, and governance at every stage of the process, from agent definition and design through development, deployment, and production operation. Let’s look at some key aspects of ADLC and how they address the unique requirements of building and operating agents. Start by defining the agent Before you start writing any code, you must clearly define the problem the agent is supposed to solve, the scope and boundaries of that problem, and the criteria for judging success. For example, a hotel booking agent could help users find appropriate hotels, compare options, and make, modify, or cancel reservations. Its scope should also clearly define what the agent is not responsible for. From this scope, establish measurable success criteria. For instance, the agent should successfully handle 95% of valid booking requests without human intervention and must never confirm a booking without first receiving explicit user approval. This gives the team a clear definition of the agent’s objectives and boundaries before deciding how to build it. Design for agentic behavior First, decide whether the use case really needs an agent; if a deterministic workflow can solve the problem, an agent may add unnecessary complexity. When agentic behavior is needed, decide on the right framework, architecture, and patterns; for instance, whether to use a single agent, one that has a supervisor along with specialized agents, or some other kind of orchestration pattern. You need to determine the tools and data the agent will require to carry out its defined scope; this should cover not only the tools the agent is allowed to use but also the limits on the operations it is permitted to carry out. For instance, a hotel booking agent would need access to tools that check availability and make reservations, but should not be given the authority to alter room prices or provide refunds. The design should also specify how the agent will handle context and memory, and how its behavior will be evaluated. The evaluation criteria and datasets should be defined, together with the acceptable limits for quality, safety, latency, cost, and any other relevant factors. The design decisions form the blueprint for implementation, after which the agent can be developed using the selected framework, with evaluation carried out throughout the development process against the success criteria set in the “define” phase described above. Evaluation goes beyond the final answer Evaluation plays a crucial role in agent development and continues throughout the agent’s life cycle. It can occur during the development phase using reference datasets and can also be carried out continuously in live or production-like environments. Evaluators assess various aspects of the agent’s behavior according to established criteria, using deterministic rules, model-based judgment, or domain-specific logic. Unlike traditional testing, agent evaluation cannot be limited to the final output. Because agents make decisions and take actions during the process, the path taken to reach the outcome is as important as the outcome itself. An agent may achieve the expected outcome while taking an inefficient path or performing actions it is not authorized to perform. Therefore, it is necessary to consider various dimensions such as accuracy, helpfulness, safety, tool use, error recovery, efficiency, reasoning quality, and tone. Different dimensions can be evaluated by different evaluators, which carry out specific checks to assess particular aspects of quality. By using multiple evaluators, you create an overall quality profile that includes both the output and the behavior that led to it. In a robotics use case we worked on at WSO2, the agent was controlling a robot and was tasked with finding a trash bin. This involved moving the robot around, capturing images, and checking those images for a trash bin. The agent eventually found the bin, but received a low path-efficiency rating. The evaluator regarded the repeated rotations and image captures as inefficient, even though these actions were necessary for the agent to understand its physical environment. The problem wasn’t with the agent but with the evaluator; to address this, we developed a custom evaluator that accounted for the environment and constraints, then used it to improve the agent’s behavior. The main takeaway is that it should not be enough to say “it works”; you must establish criteria for good agent behavior in the context of the environment in which the agent operates. Observability for agentic systems To understand how an agent behaves, you need visibility into what happens when it is executed, both during development and after it has been put into use. Traditional observability provides visibility into applications through logs, metrics, and traces. Yet agentic systems introduce new types of interactions and execution patterns that have to be understood; for example, those involving model interactions, tool calls, retrievals, interactions between agents, and the execution paths that the agents follow in order to carry out a task. Current observability foundations, such as distributed tracing, remain highly relevant to agentic systems. The problem is not tracing per se, but the absence of a common set of semantics for describing behavior specific to individual agents. Although traditional tracing is well adapted to depicting services, requests, database calls, and other application operations, concepts like model interactions, tool calls, agent handoffs, and agent execution paths need further semantics. Without common semantics, different agent frameworks will represent the same operations differently. For instance, how a tool invocation is captured will vary by framework, making it difficult to consistently understand agent behavior in a heterogeneous environment. The gap is narrowing as standards like OpenTelemetry develop common semantic conventions for agent-specific interactions. These conventions provide a consistent basis for observability tools to collect, analyze, and visualize agent behavior across frameworks. Enforcing agent boundaries Although observability lets us see what an agent is doing, visibility alone is not sufficient; the boundaries set during the design phase must also be enforced at run time. When agents use enterprise systems via various tools, such as those available through Model Context Protocol (MCP) servers, it is necessary to know which agent is making the request and what actions that agent is permitted to carry out. This, in turn, creates the need for agent identities and roles. Access-control policies can turn the boundaries set up during the design phase into permissions that specify the tools and operations an agent can call. The policies can then be enforced at the control points between the agent and the tools it accesses. The hotel booking agent is designed to search for available rooms and make reservations, but it cannot alter room prices or provide refunds. At run time, these limitations are enforced by permitting the relevant search and booking functions while refusing any requests to change the price or issue a refund. This ensures the boundaries set during the design phase are maintained while the agent operates. Governing agent-LLM interactions You need to govern how agents interact with large language models throughout their life cycle. This includes managing model usage and cost and applying the necessary safety and security policies. Agentic workflows may involve several model calls as the agent plans, uses tools, evaluates results, and iterates to reach an outcome. You need to track model and token usage, set budgets, and enforce limits to keep usage within acceptable levels. You also need to address safety and security. You can apply guardrails to model inputs and outputs to detect or prevent issues such as exposure of personally identifiable information, harmful content, prompt injection, and other policy violations. You can also define which models an agent can access and under what conditions. Together, these mechanisms keep agent-LLM interactions within the security, safety, cost, and operational limits set by the organization. Scaling ADLC across the enterprise As agent adoption grows, applying ADLC capabilities consistently becomes increasingly difficult. Different teams are likely to develop and run agents using a variety of frameworks, models, tools, and environments. As the number of agents and teams increases, maintaining consistency across them becomes harder. Evaluation, observability, identity and access, guardrails, budgets, and runtime policies could be handled with different tools and approaches, leading to fragmentation and redundant effort. This makes it difficult to apply common policies, maintain consistent controls, and gain a unified view of agents across the organization. That’s where an agent control plane proves its value. It provides a standard layer to apply and manage these capabilities consistently across the entire agent portfolio, while still enabling teams to develop agents using the frameworks, models, and tools best suited to their specific use cases. Operationalizing ADLC with an agent control plane An agent control plane provides a common way to apply and manage ADLC capabilities consistently throughout the agent life cycle. Organizations can register each agent, along with its purpose, owner, version, tools, and dependencies, to provide visibility across the agent portfolio. They can integrate evaluation requirements into CI/CD pipelines and use quality, safety, and domain-specific thresholds as gates before promoting agents between environments. At run time, identity and access policies can control which tools and enterprise systems an agent can access. Guardrails, budgets, and usage limits can govern its interactions with LLMs. Traces and metrics provide insight into agent behavior, while online evaluations continuously evaluate whether agents continue to meet expected quality and safety standards. These capabilities provide a consistent way to manage agents without forcing development teams to standardize on a particular agent framework, model, or environment. The life cycle does not end when an agent reaches production. Runtime behavior provides information that teams can use to improve the next version of the agent. When an agent’s behavior changes or falls below expected thresholds, teams can use traces and evaluation results to understand what happened. They can then improve the agent, adjust policies or permissions, update evaluations, and deploy a new version. This creates a continuous life cycle in which teams define, design, evaluate, deploy, observe, and govern agents, with what they learn during operation feeding back into the next iteration. The agent control plane provides the common foundation needed to apply these ADLC capabilities consistently as agent adoption scales across the enterprise. Establishing the foundation early Establishing this common foundation early ensures that agents are managed consistently throughout their life cycle, from design and development through to production, with the necessary security controls and visibility in place. This foundation is much easier to establish early than to retrofit later. As agent adoption grows, maintaining consistent controls becomes harder, especially as agents gain access to more models, tools, and enterprise systems while operating within defined boundaries. Organizations early in their agent journey should establish this common foundation before fragmentation and security risks become harder to manage. For organizations already experiencing inconsistent practices across teams or struggling to maintain control and visibility over agents, these are strong signals that they need an agent control plane. — New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com .