LLM-Powered Multi-Tool Architecture for Oil & Gas Data Exploration

dxc · Energy · 2024 · source Agentic: yes · promotional bias: med · source-backed · extracted with prompt 0.5.6 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Oil and gas data exploration

DXC and AWS needed an assistant that could answer oil-and-gas questions over scattered, non-standard data sources spanning text, tables, file systems, and LAS well-log formats.

Constraints:

• Oil and gas data is scattered across remote sites, offshore drilling locations, branch offices, and corporate offices.
• Relevant data appears in spreadsheets, satellite images, GIS data, and industry-specific LAS files.
• Different question categories require different processing steps.
• Conversational follow-ups need previous context such as API numbers, years, and tool results.

Architecture

DXC built an Amazon Bedrock/Claude assistant with a router, data-type-specific tools, S3-backed data access, Bedrock Knowledge Bases for semantic search, custom table and LAS code-writing tools, and a query-rewriting layer for conversational follow-ups. Smaller Claude variants handle routing while stronger models handle code generation and tool-specific reasoning.

Diagram confidence: explicit (topology described by the source).

flowchart LR
  Query_rewriter["Context-aware query rewriter"] --> Router["Claude router"]
  Router --> File_search["File search tool"]
  Router --> Semantic_search["Semantic search tool"]
  Router --> Tables_tool["Tables tool"]
  Router --> LAS_tool["LAS tool"]
  S3_store["S3 data store"] --> File_search
  S3_store --> Semantic_search
  S3_store --> Tables_tool
  S3_store --> LAS_tool

Components

Data flow

A user query first goes through a context-aware query-rewriting layer when chat history matters. The router classifies the rewritten query into file, production, directional-survey, LAS, knowledge-base, or unrelated categories, then dispatches to the appropriate tool. Tools retrieve or compute over S3-backed data, return structured outputs/resources, and the UI presents the final answer.

Why this architecture

The assistant uses multiple specialized tools because oil-and-gas questions differ by data type: some require file-name filtering, some semantic document retrieval, some tabular computation, and some LAS-specific parsing. Separating query rewriting from routing keeps each LLM task simpler and improves follow-up behavior at the cost of about one second of latency.

Models used: Anthropic Claude v2.1 · Anthropic Claude Haiku · Amazon Bedrock Knowledge Bases · LangChain XML agent · Python REPL

Scale

• DXC has more than 130,000 employees supporting 6,000 customers in over 70 countries.
  “DXC Technology is an IT services leader with more than 130,000 employees supporting 6,000 customers in over 70 countries.”article, stated
• For large oil-and-gas companies, shaving one day off time to first oil can affect cost and revenue by millions of dollars.
  “shaving even a single day off the time to first oil can impact operational costs and revenue by millions of dollars.”article, stated
• The query rewriting layer adds about one second of latency.
  “This query rewriting step adds an extra second in terms of latency, and could be toggled off, but it greatly enhances user experience”article, stated
• The workflow moves data exploration tasks from hours to minutes.
  “Data exploration tasks that took hours can now be achieved in just a few minutes, dramatically reducing time to first oil for DXC’s customers.”article, stated

Alternatives considered (roads not taken)

Single generic agent for every data type

Rejected because: DXC split tools by file name, semantic content, tables, and LAS because each question type required different processing.

LangChain/Pandas-style final answer generation after code execution

Rejected because: Sending large DataFrames back to the LLM adds latency and hallucination risk, so DXC returns Python outputs directly.

Combining query rewriting and routing in one prompt

Rejected because: The team found separate tasks more straightforward for LLMs than one overloaded prompt.

Patterns

tool-use-orchestration (orchestration)

The router directs each user question to file, text, table, or LAS tools optimized for the relevant data type.

model-routing (cost-performance)

DXC uses smaller faster Claude models for routing and more powerful Claude variants for code generation.

rag-retrieval (retrieval)

Semantic content search uses Amazon Bedrock Knowledge Bases to retrieve relevant documents before Claude answers.

query-rewriting (context)

A pre-router layer rewrites follow-up questions with missing context from prior conversation turns.

structured-output-contract (guardrails)

Router and tools require XML tags so downstream code can parse categories, answers, resources, and new queries.

Tradeoffs

Use query rewriting before routing

Chose separate rewrite layer over combining rewrite and routing in one prompt.

Rationale: The separate layer adds about one second but improves follow-up context and keeps tasks simpler for the model.

Return computed table output directly

Chose direct Python result output over LLM-authored final response over the DataFrame.

Rationale: Direct output reduces latency and avoids hallucinating or truncating large tabular results.

Use smaller models for routing and larger models for code generation

Chose task-specific Claude model variants over one model for all subtasks.

Rationale: The article directly frames routing as basic and code generation as complex, supporting a cost/latency split.

Gotchas (what bit them)

Sending large computed DataFrames back to an LLM can introduce hallucination and context-window risk.

Root cause: Traditional code agents run code and then ask the LLM to rewrite the output as a final response.

Resolution: Return the Python output directly to the user interface for table tasks.

Follow-up questions lose essential API numbers or years without conversation context.

Root cause: The basic router is stateless and only handles one user query at a time.

Resolution: Add a query-rewriting layer before routing.

Too many retrieved resources can cut off the answer.

Root cause: LLMs have limited input and output tokens when many files match a query.

Resolution: Add controls to limit retrieved context and output size.

Evaluation

The case demonstrates tool behavior with concrete sample questions over file search, semantic search, production tables, LAS files, and conversational follow-ups; it reports qualitative workflow speedup from hours to minutes.

Metrics: hours reduced to minutes for data exploration · one extra second latency for query rewriting · multiple sample tool flows over Teapot Dome data

Outcomes

• DXC and AWS built an oil-and-gas data exploration assistant with specialized LLM-powered tools.
• The assistant supports file, semantic, table, LAS, and conversational follow-up queries.
• The article reports workflows that took hours can be completed in minutes.

The assistant is framed for DXC's oil-and-gas customers, where even one day faster time to first oil can affect costs and revenue by millions of dollars.