In our previous blog post we introduced Blue, a key project as part of our compound AI systems research, targeting specifically “agentic for enterprise.” In this blog post, we will dive into more details regarding enterprise requirements and opportunities, and then discuss the rationale behind some of Blue’s conceptual designs.
Let’s begin by discussing what we expect agents and agentic frameworks to help facilitate in the enterprise context.
What does “agentic for enterprise” do?
Over the course of years, many architectural patterns (such as layered, event-driven, service-oriented) have emerged, driven by the introduction of web applications, utilization of machine learning, and the use of business intelligence. Now, we are witnessing a new era of applications that exploit “agentic workflows” for business applications. However, the jury is still out on what the right agentic architecture is.
Example Enterprise Architecture
While the architectural patterns are emerging, it is important to understand key requirements for enterprise organizations. Common across enterprises is the need to accommodate a multitude of applications and services. Typically, enterprise applications perform complex tasks with workflows comprising multiple services, fueled by data and models, through online and offline pipelines, from a multitude of data sources of various modalities (e.g., relational, graph, key-value, document).
With the introduction of “agentic” into enterprise solutions, we expect the nature of applications to change significantly: in regards to types of input fed into applications, how data is processed, transformed, and communicated, how computations are broken down, and eventually how outputs are produced and presented back to the user. For example, beyond chat-based applications, we expect to see increasingly more user input coming in natural language, which LLMs will be used to interpret. We expect data processing pipelines to use LLM-based operators to extract, process, summarize, and visualize data. LLMs will be exploited to identify user intent, prepare corresponding plans, and maybe even execute them.
Simply put, we are seeing a shift from “pre-designed” to “in situ designed” and from “direct manipulation” to “co-operative” models of applications, in regard to how data is acquired and computation is performed.
As such, we expect these evolutions in application development:
- computation moving between “non-deterministic” and “deterministic” components,
- “high-dimensional” data and “parametric” knowledge used in conjunction with “structured” data and “symbolic” knowledge,
- proprietary enterprise data, services, and models made available to “agents”, and
- more use of external providers, in regard to LLMs, agents, and services.
All the above have important implications for enterprise and agentic architectures.
What are the objectives of “agentic architecture”?
The goal of the architecture design is to improve overall performance, utility, and accountability by optimizing shared data and services across applications. At the same time, each application needs to tailor and control data and services to achieve outcomes specific to their use case. Applications have specific business logic to do so.
Key concerns of architecture design in the enterprise context are:
- Controllability: ability to have sufficient governance on the outcomes for each application and service.
- Configurability: ability to reuse existing services through customization.
- Observability: ability to capture and examine key application data to test, debug, and account for.
- Measurability: ability to collect key performance data and compute and account for system performance indicators, including cost.
- Scalability: ability of the system to scale to the size and complexity of data, services, and applications in line with the expected performance and quality requirements.
With agentic applications, these concerns simply carry over to rest on the agentic architectures to deliver and integrate, but they introduce challenges.
Making enterprises ready for “agentic”
A key requirement for enterprise agentic frameworks is to integrate existing enterprise resources and prepare them for “agentic workloads” to fuel the new set of “agentic applications.” This includes integrating existing proprietary data, models, and services.
What does making them ready for agentic mean? At a minimum, it means the ability to:
- find available resources in the enterprise,
- discover new resources as they become available,
- match resources to application needs, and,
- integrate resources to utilize them in workflows, including:
- how to use such resources.
- how to communicate data and work resources.
Additionally, in an enterprise context, it also means ability to:
- log and record resource use (including perf data) for observability and accountability,
- optimize resource utilization for multiple objectives (cost, accuracy, response time), and potentially,
- learn from usage data to improve all above aspects (e.g., discover, match, integrate, optimize).
Blue Concepts
At the heart of Blue lies a foundational shift in how enterprise systems interact with increasingly complex, intelligent, and dynamic workflows. Traditional enterprise architectures rely heavily on static configurations, rigid interfaces, and pre-defined logic. In contrast, Blue introduces compound AI system design principles—where modular, interoperable components (like agents, planners, and registries) are composed into intelligent workflows capable of responding to real-world complexity in real time. This design encourages a hybrid approach where deterministic systems and LLM-based reasoning agents operate in tandem, coordinated through shared infrastructure and common abstractions. These abstractions—such as registries—are key to making enterprise resources (like data, models, and services) discoverable, reusable, and controllable by agentic systems. In the next section, we focus on one of these key abstractions: registries.
Registries
Registries are essentially repositories that store records about the resources. For example, a data registry stores metadata about data sources in the enterprise. A model registry stores metadata about the available proprietary models in the enterprise. As such, registries are key touchpoints to the existing data infrastructure to find, discover, match, and integrate them into agentic workflows.
Depending on the type of resources, registries can store different kinds of data, metadata, properties, and logs. For example, a data registry could have names and descriptions of the tables, columns, sample values, database connection information, and past queries. An agent registry in a similar fashion could contain names of the available agents, their descriptions, properties to configure settings, input and output data format and specifications, and beyond.
A key function of the registry is to support finding, discovering, and matching resources. For example, a component such as a planner needs to be able to find and match a resource to a specific task in the plan. To be able to do so, the registry can be searched to find matching agents and services. Furthermore, by utilizing the metadata along with the logs (such as query logs), such information can be used to build models to learn representation of said resources to help improve search quality.
For compute resources such as agents and services, the registry can also include input and output parameters, inclusion/exclusion rules, deployment information such as Docker images, and deployment configurations, along with other properties. Such information can be used in determining how to use and communicate with the resources. For example, the registry can contain names and descriptions of parameters, data types, but also connection information (e.g IP address) of the relevant services.
A data registry typically includes names, descriptions, and details about data at various levels of granularity (e.g., tables within a database), encompassing data schema and database connection specifics. The registry also incorporates vector metadata, which captures embeddings derived from learned representations of metadata (e.g., schema details), data contents (e.g., values), structural elements (e.g., schema relationships), and logs (e.g., query histories). Moreover, the data registry serves as a centralized repository where information, such as available indices, is stored. This unified interface allows any agent or component to seamlessly access and utilize information in a consistent manner.
Logging functionality within registries is very important, not only in improving observability and accounting, but also in optimization. Such data can include performance metrics for a model registry, which can be very useful for an optimizer when choosing the right model for the data and task at hand.
Developers (and agents) can interact with the registries through various interfaces like APIs and web applications. They can register new agents, update metadata, derive new agents from existing ones, and browse and search the registry. This interface provides comprehensive functionality for managing agents within the ecosystem.
In conclusion...
Registries play a crucial role in making enterprises agentic. Through various registries, enterprise resources such as proprietary data, services, and models can be discovered and integrated into agentic workflows. Each registry is available for any agent to utilize, including more sophisticated components such as planners.
We strongly believe that, for “agentic workflows” to be truly embraced by the enterprise, many unique enterprise factors need to be taken into account. Simply put, it is not practical to drop what already exists—abandoning years of investment and context—and start completely fresh.
With these design objectives in mind, we made a first attempt to address these concerns and released Blue v0.9. However, it is just the beginning. We would like to engage with the community to shape future versions.
Next post
In the next blog post, we will introduce streams, a key orchestration concept in Blue. We will show how streams allow and facilitate communication and coordination among agents and interface to data and services. Streams will be our answer to the key challenge of integrating enterprise resources. Furthermore, streams will help facilitate reusability and scalability in the enterprise. In future posts, we will cover other key components in Blue, including planners and operators, and eventually put it all together in our overall blueprint architecture.
Sounds interesting, right? Want to try it now?
Please go to the repo and follow the installation instructions: Blue v0.9
Written by Eser Kandogan and Megagon Labs
