How the Next Generation BluCARE Intelligence Support Agent v2.0 Will Work
This article describes the planned version 2 architecture and capabilities. These functions are not all available in the current Support Agent.
Overview
The next-generation BluCARE Intelligence Support Agent will evolve from a question-answering assistant into an intelligent, extensible, workflow-driven support platform.
The current Support Agent primarily retrieves ticket information, searches historical support knowledge, and generates an answer. Version 2 will be designed to understand the complete support context, select and execute proven resolution workflows, create new workflows when necessary, coordinate specialized agents, and learn from completed support cases.
The objective is not simply to answer a support question. The objective is to help resolve the underlying problem -- consistently, safely, and as autonomously as the situation allows.
Current Support Agent Versus Version 2
| Capability | Support Agent v1.0 | Support Agent v2.0 |
|---|---|---|
| Answer support questions | Yes | Yes |
| Retrieve ticket information | Yes | Yes |
| Read ticket conversations and comments | Yes | Yes |
| Search historical support knowledge | Yes | Yes, with continually updated knowledge |
| Understand customer and building context | Limited | Expanded |
| Select a resolution workflow | No | Yes |
| Execute predefined workflows | No | Yes |
| Create a new workflow | No | Planned |
| Update tickets and operational systems | No | Planned through authorized tools |
| Coordinate specialized agents | Limited | Yes |
| Learn from newly resolved cases | Not automatically | Yes |
| Improve skills, tools, and workflows | No | Long-term objective |
Core Architectural Principles
Standardized MCP Agent Interface
The version 2 Support Agent will expose its capabilities through a standardized Model Context Protocol, or MCP, interface.
MCP will provide a common way for Oracle, Fleet, and other authorized systems to communicate with the Support Agent. Instead of embedding every new capability directly into Oracle, independently developed agents and tools will be able to connect through a consistent interface.
This approach will make it easier to:
- Add new specialized agents
- Add or replace tools
- Connect new knowledge sources
- Reuse capabilities across multiple agents
- Maintain agents without continually changing Oracle's core code
- Expand from one Support Agent to potentially hundreds of specialized agents
Modular and Reusable Architecture
The version 2 Support Agent will be built using a standard agent architecture that can be reused throughout BluSKY.
Each agent will follow a defined structure for:
- Memory
- Skills
- Tools
- Workflows
- Knowledge access
- MCP communication
- Orchestration
- Review and validation
The Support Agent will be the first production-quality implementation of this architecture. Once validated, the same pattern can be used to create additional agents without redesigning the platform each time.
Workflow-Centric Execution
Version 2 will distinguish between answering a question and completing a support process.
When a known and repeatable issue is identified, the Support Agent will use a tested workflow rather than relying entirely on generative reasoning. Common problems -- such as password resets, account-access issues, configuration checks, or standard troubleshooting procedures -- can follow deterministic steps.
A workflow may define:
- Required information
- Diagnostic steps
- Decision points
- Tools to invoke
- Records to retrieve
- Changes that may be performed
- Validation procedures
- Ticket updates
- Escalation conditions
- Completion criteria
Using tested workflows will produce more consistent results and reduce the risk of skipping an important step.
How a Support Request Will Be Processed
The planned version 2 request-processing sequence is:
- A user submits a question, problem, or support request.
- Oracle identifies the type of request and delegates it to the Support Agent.
- The Support Agent gathers the available customer, building, system, device, configuration, and ticket context.
- It reads the complete ticket conversation and previous actions.
- It searches current documentation and continually updated historical support knowledge.
- It determines whether an approved workflow already exists for the problem.
- If a workflow exists, Fleet coordinates its execution.
- The Support Agent monitors the results and evaluates whether the issue has been resolved.
- The ticket and related records are updated through authorized tools when appropriate.
- The outcome is validated, documented, and communicated to the user and Support Team.
- The completed case becomes new knowledge that can improve future responses and workflows.
Using Existing Workflows
When the Support Agent recognizes a known issue, it will search for a matching workflow.
The agent will evaluate factors such as:
- Reported symptoms
- Product module
- Customer and building
- System and device configuration
- Error messages and event history
- Actions already attempted
- Similar historical cases
- Available tools and permissions
- Risk and potential customer impact
If an appropriate approved workflow exists, the agent will select it and ask Fleet to coordinate its execution.
This reduces the need to reinvent a solution each time the same type of issue occurs.
Autonomous Workflow Creation
The target architecture will allow the Support Agent to respond when no suitable workflow exists.
The planned workflow-creation cycle is:
- Determine that no approved workflow adequately addresses the problem.
- Gather relevant knowledge, examples, tools, and historical resolutions.
- Generate a proposed workflow.
- Submit the proposed workflow for review and validation.
- Test the workflow against the current problem or an appropriate test scenario.
- Execute it after the required approval is received.
- Evaluate whether it resolved the issue correctly.
- Revise unsuccessful or incomplete steps.
- Repeat the validation cycle as necessary.
- Preserve a proven workflow for future reuse.
A dynamically created workflow should not automatically become a permanent production workflow simply because it worked once. It must be tested, reviewed, and proven before promotion into the approved workflow library.
Over time, this process will allow the system to convert new support experience into reusable operational knowledge.
Fleet's Role
Fleet is expected to serve as the primary workflow execution and coordination engine.
In the planned architecture:
- Oracle receives requests, determines intent, and delegates work.
- The Support Agent understands the support problem, gathers context, and determines the appropriate resolution approach.
- Fleet coordinates and executes the selected workflow.
- Specialized agents and tools perform individual actions within the workflow.
- The Support Agent evaluates the results and communicates the outcome.
Fleet may coordinate activities such as:
- Calling diagnostic tools
- Querying systems
- Invoking specialized agents
- Managing workflow steps and dependencies
- Tracking execution status
- Handling retries and exceptions
- Requesting approval when required
- Verifying completion criteria
- Returning results to the Support Agent
This separation allows the Support Agent to focus on understanding and resolving the support problem while Fleet manages the mechanics of multistep execution.
Richer Customer and Building Context
Version 2 is expected to operate with substantially more context than the current Support Agent.
Depending on the request, the Support Agent should be able to understand:
- The customer organization
- The affected building or facility
- The applicable BluSKY system
- Product modules in use
- Device inventory
- Device status and configuration
- System relationships
- Relevant projects
- Current and previous support tickets
- Previous actions and communications
- Similar problems at the same building
- Similar problems across other systems
- Known resolutions and documented procedures
This context will help the agent distinguish between a general product question and a problem involving a specific customer, building, system, or device.
Continuously Updated Support Knowledge
The historical support RAG dataset has not been comprehensively refreshed since approximately March 2025. Version 2 must correct this limitation.
The future ingestion process should:
- Regularly ingest newly created and resolved support cases
- Process new ticket conversations and resolutions
- Add validated troubleshooting knowledge to the RAG dataset
- Update existing knowledge when a better resolution is discovered
- Make recent support experience available to the Support Agent
- Prevent obsolete or superseded guidance from remaining the preferred answer
This will create a continuous learning cycle:
- A support problem is reported.
- The problem is investigated and resolved.
- The resolution is validated.
- The case is processed into reusable knowledge.
- Future tickets benefit from that experience.
Memory, Skills, Tools, and Workflows
Version 2 will treat four capabilities as fundamental parts of every agent.
Memory
Memory provides retained context, including relevant prior interactions, support history, customer information, and lessons from previous work.
Skills
Skills define what the agent knows how to do. A skill may contain specialized instructions, decision logic, required resources, and guidance for performing a particular type of support work.
Tools
Tools allow the agent to retrieve information or perform authorized actions. These may include database queries, ticketing operations, diagnostic functions, configuration checks, and other BluSKY capabilities.
Workflows
Workflows organize skills and tools into repeatable, multistep processes with defined inputs, decisions, validations, and completion criteria.
Workflows will be stored so they can be found, evaluated, reused, improved, and -- after sufficient validation -- promoted into permanent system capabilities.
Ticket and System Actions
Unlike the current read-only implementation, version 2 is intended to support authorized operational actions.
Depending on the approved tools and workflow, future capabilities may include:
- Adding information to a ticket
- Updating ticket status
- Updating assignment or classification
- Recording diagnostic results
- Requesting additional information
- Documenting actions performed
- Closing a ticket after resolution is verified
- Performing approved system or configuration actions
- Escalating an issue when defined conditions are met
These actions will be governed by the workflow, available permissions, required approvals, and the risk associated with the action.
Validation and Improvement
The Support Agent must determine whether a workflow actually solved the reported problem.
Validation may include:
- Confirming that the expected system state was achieved
- Rerunning diagnostic checks
- Comparing results with defined completion criteria
- Confirming the outcome with the customer or Support Team
- Monitoring for recurrence
- Recording unsuccessful steps
- Escalating when automated resolution is not appropriate
If a workflow fails, the agent should not blindly repeat the same process. It should analyze the failure, adjust the proposed approach, and proceed through another review and validation cycle.
Long-Term Autonomous Evolution
The broader long-term objective extends beyond improving a single Support Agent.
The platform is intended eventually to support the autonomous creation and refinement of:
- Agents
- Skills
- Tools
- Workflows
- Knowledge sources
- Orchestration patterns
The system should also be able to:
- Identify overlapping tools and workflows
- Eliminate or consolidate duplicate capabilities
- Improve inefficient workflows
- Replace obsolete procedures
- Test experimental capabilities
- Promote proven capabilities into permanent assets
- Retain lessons from successful and unsuccessful executions
This will allow the agent ecosystem to improve as BluB0X products, customer environments, and support requirements evolve.
Proposed Implementation Path
The planned implementation will begin with one production-quality version 2 Support Agent.
Phase 1: Define the Standard Architecture
Establish the common structure for agents, including MCP communication, memory, skills, tools, workflows, orchestration, and validation.
Phase 2: Build the MCP-Based Support Agent
Rebuild the Support Agent around standardized MCP interfaces so it can interact consistently with Oracle, Fleet, and other agents.
Phase 3: Integrate Fleet
Connect the Support Agent to Fleet so Fleet can coordinate and execute multistep support workflows.
Phase 4: Create the Initial Workflow Library
Develop and validate workflows for the most common and repeatable support requests.
Phase 5: Expand Support Context and Knowledge
Add deeper customer, building, device, configuration, and ticket context. Refresh historical support RAG content and establish continual ingestion of new cases.
Phase 6: Validate With Production Problems
Use real support cases to evaluate workflow selection, execution, validation, escalation, and ticket documentation.
Phase 7: Expand the Architecture
Use the proven Support Agent architecture as the foundation for additional specialized agents across BluSKY.
What Version 2 Will Mean for the Support Team
The next-generation Support Agent is intended to help the Support Team:
- Investigate issues faster
- Apply consistent troubleshooting procedures
- Reduce repetitive manual work
- Avoid repeating previously solved investigations
- Keep tickets better documented
- Make current support knowledge easier to find
- Convert successful resolutions into reusable workflows
- Continue working through multistep problems
- Escalate cases with more complete diagnostic information
- Resolve common issues more quickly and consistently
The Support Team will remain important to the system's success. Team members will help validate new workflows, identify incorrect or incomplete guidance, confirm resolutions, handle exceptions, and turn expert support knowledge into repeatable BluCARE Intelligence capabilities.
Expected Outcome
The version 2 BluCARE Intelligence Support Agent will move beyond passive question answering. It will become an intelligent support platform capable of:
- Understanding the customer, building, system, device, and ticket context
- Retrieving current and historical support knowledge
- Selecting proven resolution workflows
- Creating proposed workflows for new problems
- Coordinating execution through Fleet
- Using specialized agents, skills, and tools
- Performing authorized ticket and system actions
- Validating whether the problem was resolved
- Learning from newly completed support cases
- Continually improving the wider agent ecosystem
The ultimate objective is a BluCARE Intelligence Support Agent that does not merely suggest what someone might do next. It helps carry the support problem through investigation, action, validation, documentation, and resolution.