Skip to main content

How the Current BluCARE Intelligence Support Agent v1.0 Works

Overview​

The current BluCARE Intelligence Support Agent is a first-generation support assistant implemented within the Oracle architecture. It follows a structured, largely fixed request-processing pattern.

Its primary purpose is to answer support-related questions by combining:

  • Current information from support-ticket and project-related database tables
  • Existing ticket conversations, comments, and attachments
  • Historical support knowledge stored in a retrieval-augmented generation (RAG) knowledge base

The current Support Agent is best understood as a context-enriched question-answering system. It can gather and interpret support information, but it does not yet perform autonomous workflows or modify support tickets.

High-Level Architecture​

When a user submits a support question, the request moves through the following process:

  1. The user submits a question through the BluSKY chat or user-interface layer.
  2. The request passes through the applicable HTTP and service-bus handlers.
  3. Oracle's supervisor agent routes the request to the Support Agent.
  4. The Support Agent uses SQL tools to retrieve relevant information from support-related database tables.
  5. The agent combines the user's original question with the retrieved database context.
  6. The enriched request is sent to the historical support knowledge base.
  7. The RAG system retrieves relevant support cases, documentation, problems, and solutions.
  8. The Support Agent evaluates the combined information and generates a response.
  9. The response is returned to the user through the original interface.

How the Support Agent Answers Questions​

The Support Agent has access to several tools. Its primary tools are SQL-based retrieval tools that allow it to examine current support information.

When a question is received, the agent generally:

  1. Determines what ticket, project, or support information is needed.
  2. Searches the applicable support database tables.
  3. Retrieves relevant ticket details and background information.
  4. Reviews the existing conversation and comments when a ticket ID is available.
  5. Combines that information with the user's question.
  6. Submits the enriched question to the historical support RAG system.
  7. Uses the returned knowledge to formulate an answer.

This approach gives the agent access to both the current support record and historical information that may help explain or resolve the issue.

Knowledge Sources​

The Support Agent currently uses two primary categories of information.

1. Current Support Database Information​

The Support Agent can use SQL tools to retrieve information from support-related database tables. Depending on the request, these tools can:

  • Search for support tickets
  • List tickets based on specified filters
  • Retrieve detailed ticket information
  • Read ticket conversation history
  • Retrieve internal or external comments
  • Access information about ticket attachments
  • Retrieve relevant project-related information
  • Gather supporting information needed to understand the reported issue

This database access allows the Support Agent to incorporate the current state and history of a ticket into its answer.

2. Historical Support Knowledge​

The Support Agent also queries a RAG-based knowledge source built from historical support content.

RAG allows the agent to search previously processed support information for relevant:

  • Problems
  • Symptoms
  • Troubleshooting information
  • Explanations
  • Resolutions
  • Related historical cases
  • Product and support documentation

The Support Agent sends the RAG system an enriched query containing both the user's question and the context gathered from the current support database. This gives the RAG system more information with which to locate useful historical knowledge.

Ticket-Specific Processing​

When the request includes a ticket ID, the Support Agent follows a more ticket-focused process:

  1. Retrieve the ticket record.
  2. Read the existing ticket conversation history.
  3. Review previous comments associated with the ticket.
  4. Identify the issue, symptoms, history, and actions already taken.
  5. Call the historical support RAG tools for relevant knowledge.
  6. Generate and execute additional SQL queries when more context is required.
  7. Retrieve related supporting information from the database.
  8. Combine the ticket history, database information, and historical knowledge.
  9. Generate a response using all available context.

The Support Agent's system prompt specifically requires it to read the existing conversation history before proceeding with additional retrieval and SQL operations. This is intended to prevent the agent from answering without understanding what has already occurred on the ticket.

Prompting Strategy​

The Support Agent does not currently retrieve its prompts from a centralized prompt database.

Instead:

  • Common prompts and instructions exist within the broader Oracle agent framework.
  • The Support Agent has its own agent-specific prompts.
  • Those prompts are embedded directly within the Support Agent implementation.
  • Much of the current request-processing behavior is explicitly defined or hard-coded.

This reflects the fact that the Support Agent was created rapidly as a pragmatic first version. Future versions may externalize prompts and make agent behavior more configurable, but that is not part of the current implementation.

Current Capabilities​

The existing Support Agent can:

  • Answer support-related questions.
  • Search support-ticket database tables.
  • Retrieve detailed ticket information.
  • Read prior ticket conversations.
  • Incorporate previous ticket comments into its responses.
  • Access information about ticket attachments.
  • Search for tickets using filters.
  • Retrieve relevant project and support context.
  • Query historical support knowledge through RAG.
  • Search available documentation and retrieved knowledge sources.
  • Combine current ticket information with historical support knowledge.
  • Generate a context-aware response for the user.

Current Limitations​

It is important for the Support Team to understand what the current Support Agent does not do.

No Autonomous Workflows​

The Support Agent does not currently:

  • Execute automated support workflows
  • Dynamically create workflows
  • Independently coordinate a multistep resolution process
  • Continue working autonomously until a case is resolved
  • Assign and manage work across other agents or Support Team members

Its current role is retrieval and response, not autonomous case management.

No Ticket or Database Updates​

The Support Agent currently has read-only behavior. It does not write information back to the support system.

It cannot:

  • Update a support ticket
  • Add information to a ticket
  • Close a ticket
  • Change a ticket's status
  • Change ticket ownership or assignment
  • Execute database update queries
  • Execute database insert operations
  • Add or modify records in another system

Any ticket changes resulting from the agent's response must currently be made through the normal support process.

Limited Autonomous Reasoning​

The existing implementation is not yet a sophisticated autonomous agent. It primarily follows a defined retrieval-and-response pattern:

  1. Gather database context.
  2. Search historical support knowledge.
  3. Generate an answer.

It does not independently build new workflows, take corrective action, or manage a case through completion.

No Building-Specific Historical Retrieval​

The current historical support RAG implementation does not use building IDs to locate building-specific cases.

Historical support cases were processed with building identifiers hidden or excluded. The historical knowledge therefore focuses primarily on the documented problem and solution rather than the identity of the building where the problem occurred.

The agent may receive current building or system context from support database tables, but it cannot presently use a building ID to search the historical RAG knowledge base for all prior cases associated with that specific building.

Learning From New Support Cases​

The historical support cases have reportedly not been reprocessed into the RAG knowledge base since approximately March 2025.

As a result:

  • New support cases are not automatically being added to the historical support knowledge base.
  • Recent cases may be available through the current support database but not through historical RAG retrieval.
  • Knowledge learned from newly resolved cases is not automatically available to the RAG system.
  • Delta-RAG processing has not yet been implemented for support cases.

A data-ingestion mechanism already exists, so new support cases can eventually be processed through the existing RAG pipeline. However, that ingestion is not currently operating as an automatic, continuous learning process.

This distinction is important: the Support Agent may read a current ticket directly from the database, but that does not mean the ticket has been incorporated into the reusable historical knowledge base.

Relationship to Oracle​

The Support Agent operates as one component within the broader Oracle architecture.

Oracle provides architectural capabilities such as:

  • Supervisor-agent orchestration
  • Request routing
  • Plug-and-play agent components
  • Project-management orchestration elements
  • Support-ticket agent integration

Oracle's supervisor agent can route a request to the Support Agent, but the current Support Agent remains narrowly focused on support information retrieval and response generation. It does not yet use the broader autonomous, workflow-driven capabilities planned for future versions of Oracle, Fleet, and BluCARE Intelligence.

What the Support Team Should Expect​

The current Support Agent should be used as an information and research assistant. It can help the Support Team:

  • Understand the history of a ticket
  • Locate potentially relevant historical resolutions
  • Summarize existing ticket conversations
  • Identify useful troubleshooting information
  • Answer questions based on available support knowledge
  • Reduce the time required to research an issue

For the best ticket-specific response, the request should include the ticket ID whenever it is available.

The Support Team should not assume that the agent:

  • Has access to every case created after the last RAG ingestion
  • Has learned automatically from recently resolved cases
  • Has found all cases associated with a particular building
  • Has updated the ticket after producing an answer
  • Will continue working on the case after returning its response
  • Has independently verified that a proposed resolution is correct for the current environment

The agent's response should therefore be treated as informed support guidance that may still require validation by the Support Team.

Summary​

The current BluCARE Intelligence Support Agent is a retrieval-focused assistant that:

  • Receives support questions through Oracle.
  • Uses SQL tools to gather current ticket and database context.
  • Reads prior ticket conversations and comments.
  • Queries a RAG knowledge base containing historical support information.
  • Combines the available information to generate a response.

It does not currently perform workflow automation, update tickets, change ticket statuses, write to databases, continuously learn from new cases, or autonomously manage a support issue through resolution.

This first-generation implementation provides the foundation for a more advanced BluCARE Intelligence capability. Today, however, its primary value is helping the Support Team find, combine, and interpret relevant information more quickly.