TGS runs seismic-imaging and subsurface-processing workflows around the clock across seven offices in Houston, Rio de Janeiro, London, Cairo, Oslo, Calgary and Kuala Lumpur, spanning 15 time zones. The work never stops, but expert support has historically been bound by local business hours. The result is a structural gap: a job fails late in one region, hours before the team that understands the error comes online in another. High-performance compute (HPC) sits idle and deadlines are at risk while a geoscientist searches for a half-remembered runbook across the legacy issue tracker, Jira, Confluence, and Microsoft SharePoint knowledge bases.
The knowledge needed to resolve most failures already existed inside TGS. It was fragmented across systems with different permission models and locked in the heads of a few senior experts. To make that knowledge available to every geoscientist, TGS built Scout (Video 1), a production, citation-grounded support agent using AWS Quick. This post describes how TGS designed Scout and the architecture behind it. It also covers the measured outcomes across its global rollout and the lessons that shaped its evolution from a knowledge-search tool into an agent that now takes action on geoscientists’ behalf.
Scout’s capability grew through three deliberate stages, and today it operates at the third:
- Knowledge and search – Make fragmented, permission-gated institutional knowledge instantly findable, meeting the data at its source.
- Conversational assistant – Understand context and return cited, step-by-step answers inside the tools geoscientists already use.
- Agentic AI (where Scout runs today) – Move from advising to acting: opening and updating tickets, maintaining documentation, and remediating routine failures on the geoscientist’s behalf, with human review gating high-impact actions.
Most enterprises are using generative AI, but few have moved beyond conversational assistants to scaled, agentic workflows. McKinsey finds that while 62 percent of organizations are experimenting with AI agents, only 23 percent have scaled one. Scout reached agentic operation while sustaining production-grade quality: across 35,000 responses over eight months, 99 percent were grounded in citations and 70 percent were rated accurate by users. That accuracy is on par with human-agent first-contact resolution at a fraction of the time and cost, and inside the approximately 65–80 percent range reported for enterprise Retrieval Augmented Generation (RAG) assistants. Scout cut time-to-solution-discovery from two-to-three hours to under three minutes, a 40–60x gain. That performance drove fully organic, voluntary adoption to 322 users and returned roughly 1,590 productivity days worth hundreds of thousands of dollars (Table 2).
Video 1: Cutting time-to-solution-discovery from hours to minutes. A geoscientist asks Scout and gets cited, step-by-step guidance inside the tools they already use
The operational challenge
Seismic processing runs continuously, but expert support ran on business hours. A late-day failure in one region could sit for hours until the support or owning team came online in another time zone. Junior geoscientists escalated, and senior ones became bottlenecks for routine questions. That gap turned routine failures into slower resolutions, idle compute, and avoidable escalations (Table 1).
| Pain point | Root cause | Business impact |
| After-hours job failures | No 24/7 support staffing | Hours of downtime per incident |
| Fragmented documentation | Jira, legacy issue tracker, Confluence, and SharePoint silos | Time-consuming information retrieval |
| Expert-knowledge bottlenecks | Undocumented expertise | Person-dependent, fragile knowledge |
| 15 time zones of operations | Global offices, local support hours | Idle compute, missed deadlines |
Table 1: The structural gap between round-the-clock operations and business-hours support
Documentation existed, but knowledge did not persist
Runbooks, standard operating procedures (SOPs), and issue history were scattered across Jira, legacy issue tracker systems (replaced by Jira), Confluence, and SharePoint. These four systems had different permissions, search, and freshness. Each team captured its own slice of a workflow, never the end-to-end picture, and the sharpest troubleshooting steps lived only in a few senior experts’ heads. When a job failed after hours, the answer usually existed somewhere, but finding it took precious time.
The solution: Scout on AWS Quick
TGS built Scout using AWS Quick with RAG to ground every response in validated proprietary knowledge across Confluence, SharePoint, and Jira. Scout is not a general-purpose chatbot. It is engineered around three non-negotiable principles.
- Mandatory source grounding – Scout minimizes hallucinations and unsupported responses by grounding answers in retrieved, validated TGS content. If sufficient supporting evidence can’t be retrieved, Scout is designed to withhold a definitive response rather than generate an unsupported conclusion.
- Permission-aware retrieval – Scout respects each source system’s existing access controls. Entitlements are attached to every chunk and filtered before the model sees them, so a user can only retrieve content they are already cleared to see. TGS proved the access control list (ACL) feature in Quick when the user could not retrieve data they lacked access to in the source system.
- Augment, not replace – Scout extends the reach of expert teams and captures institutional knowledge as a durable organizational asset. Even as it takes action, it keeps humans in control of complex judgments.
What Scout does today
Scout now operates as an agentic assistant. It recognizes error patterns and returns step-by-step resolution guidance with linked citations. It retrieves across Confluence, SharePoint, and Jira through a single conversational interface in the AWS Quick web app and the AWS Quick browser extension, and it will soon be embedded in TGS’s Seismic Imaging Processing Platform. Where a geoscientist confirms, it acts: it opens and updates Jira tickets directly from an interaction and keeps documentation current as resolved queries reveal gaps. High-impact actions are gated behind human review before execution. Scout operates natively in multiple languages, including English, Spanish, Portuguese, French, Arabic, Polish, and Mandarin, and extends to any language covered by TGS’s employees and documentation. It preserves full citation transparency, so geoscientists can verify in one click exactly where each answer originated.
Governance through GeoCouncil
GeoCouncil, a team of about 13 geoscientists representing more than 300 colleagues at TGS, drove Scout selection by prioritizing use cases through survey input and validating the product design. It then served as the initial pilot cohort, provided feedback that drove refinement, and championed adoption across Imaging and Technology. This gave Scout a credible internal mandate before a single office went live. The rollout was deliberately phased to de-risk a global deployment and let trust compound office by office. A pilot cohort in Rio de Janeiro resolved its first production queries immediately. Subsequent phases extended Scout to London, Cairo, Oslo, Houston, Calgary and Kuala Lumpur across 15 time zones.
How Scout works
Scout is a retrieval-grounded agent, not a fine-tuned model. Its correctness comes from disciplined retrieval over governed sources, strict citation enforcement, and a feedback loop that continuously improves answer quality. This is the same foundation that makes it safe to let Scout take action. Video 2 shows Scout in action. A geoscientist hits a failed job in LogViewer and asks Scout for help without switching tools. Scout diagnoses the issue through a grounded, context-aware conversation that pulls in real HPC alerts and prior maintenance history instead of boilerplate. Once the user confirms, Scout opens a complete Jira ticket for the Operations team from inside the same chat.
Video 2: Scout in action in a live demo. A geoscientist investigates a failed job in the viewer and asks Scout, which returns grounded guidance and can open a Jira ticket from the same conversation
End-to-end data flow
Every Scout answer follows the same governed path from systems of record to grounded response and back again with permissions and provenance preserved at each step. Figure 1 shows the full data flow followed by key architectural components.
Figure 1: Scout end-to-end architecture on AWS Quick, showing permission-aware retrieval, citation-grounded generation, agentic actions back into the source systems, and a feedback loop over Confluence, SharePoint, and Jira
- Source systems – Confluence, SharePoint, and Jira hold the validated runbooks, SOPs, incident history, and institutional knowledge geoscientists depend on. These remain the systems of record. Scout reads from and writes back to them rather than displacing them, meeting the data at its source.
- Connectors and ingestion – Managed connectors sync content and metadata, including each item’s native ACL, into the AWS Quick index. Incremental sync keeps the index current and ages out stale content, so answers reflect the latest documentation.
- Indexing – Ingested content is chunked and indexed for semantic and keyword retrieval, with source metadata and permissions preserved on every chunk, so entitlements travel with the data.
- Permission-aware retrieval – At query time, Scout retrieves only the chunks the requesting user is entitled to see, combining semantic and keyword relevance to assemble a grounded context set.
- Citation-grounded generation – AWS Quick composes an answer constrained to the retrieved context, emitting step-by-step guidance with inline citations back to the source documents. Grounded, not guessed.
- Agentic actions – When an interaction calls for action, Scout executes it against the source systems. For example, it creates or updates a Jira ticket or proposes a documentation update. High-impact actions are routed through human review before they commit.
- Conversational front end – Geoscientists interact with Scout in the AWS Quick web app or browser extension, and soon in TGS’s Seismic Imaging Processing Platform, reducing adoption friction by meeting users where they already work.
- Feedback and telemetry – Post-interaction feedback and usage telemetry feed answer-quality monitoring, informing where documentation and coverage should improve next.
Trust by design
Scout treats trust as a structural property, not an afterthought. That matters now that Scout acts, not only advises. Every answer is grounded in live sources rather than a fine-tuned model, so responses stay current as documentation changes and carry one-click grounded citations. Permissions are enforced at retrieval, not after. Entitlements travel with the data, eliminating a whole class of data-leak failures in exchange for the tighter connector discipline TGS accepted deliberately. Access runs through single sign-on with multi-factor authentication (MFA), and Scout reads and writes within TGS’s governed systems of record rather than copying knowledge into a new silo. High-impact actions stay gated behind human review, and by living inside the tools geoscientists already use, adoption cost was minimal.
Measurable impact
“Before Scout, a midnight job failure meant 2–3 hours of searching and hoping to find the right answer. Now our experts get cited, step-by-step guidance in minutes, and they trust it because they can see exactly where the answer came from.”
— Jérôme Cousin, Vice President, Enterprise IT / CIO
Scout delivers consistency at scale that frees experts to focus on complex problem-solving. The pattern that captures it best is a single interaction: a Houston geophysicist hit a job error at 6 p.m., just as regional support was winding down. Before Scout, that would have become an overnight escalation: a ticket, an idle HPC queue, and a delayed task or potentially a delayed deliverable. Instead, the geoscientist asked Scout, received cited step-by-step guidance, and resolved it in moments. No ticket was ever created. Multiplied across the organization with Scout’s global rollout, this pattern returned roughly 1,590 productivity days and created value in the high hundreds of thousands of dollars in the first eight months. It turned hours of dependency into minutes of self-service.
| Metric | Result |
| Success rate | 99% of user queries returned a response grounded in citations. |
| Accuracy rate | 70% of responses were rated accurate by users. Scout is approaching human-agent first-contact resolution which commonly sits in the ~70–75% range, at a fraction of the time and cost. Published and vendor-reported figures for answer accuracy or “correct resolution” in enterprise RAG assistants have broadly clustered in the ~65–80% range (Sun et al., 2026; Hamilton et al., 2026). |
| Time-to-solution-discovery | Two to three hours to under three minutes, a 40–60x improvement (for example, a 6 p.m. job error resolved independently, no ticket created). |
| Adoption | 322 cumulative registered users and more than 100 weekly active users (Figure 2) across 15 time zones. This is fully organic, voluntary adoption. |
| Productivity value | About 1,590 productivity days returned, with value created in the high hundreds of thousands of dollars. |
Table 2: Verified Scout outcomes across 35,000 responses over eight months from March through October 2026
Lessons learned
Three choices made Scout work, and three more are worth doing differently next time. Citation transparency drove trust: visible provenance was the single biggest factor in geoscientist confidence, turning answers they could not check into ones they could verify, and eventually an agent they were willing to let act on their behalf. Permission-aware retrieval was non-negotiable, protecting sensitive content and earning the security sign-off that let Scout write back into the source systems. And organic adoption beat any top-down mandate, producing durable usage and real advocates rather than compliance clicks. In hindsight, we would instrument documentation-gap detection from day one, so unanswered questions automatically flag missing or stale content. Define the agentic action model earlier, since geoscientists immediately wanted Scout to act, not only advise, which would have shortened the path to Stage 3. And capture resolution-time baselines per error class before launch, to quantify the savings even more precisely.
Conclusion
Scout shows that institutional knowledge does not need to depend on who is online. TGS grounded a RAG agent in validated sources, enforced permissions at retrieval, and met geoscientists in the tools they already use. The result: resolution time dropped from hours to minutes, and organic adoption alone returned about 1,590 productivity days. The path is repeatable: start with a credible pilot cohort, ground citations, enforce permissions by design, and let value drive adoption.
Next steps
- Explore AWS Quick – Visit the AWS Quick service page for an overview of capabilities including Flows, Automations, and Research.
- Go deeper on agentic AI – Read Building Agentic AI Workflows with AWS Quick.
- Ground your answers – Review Retrieval Augmented Generation on AWS for patterns to anchor generative AI in your own trusted content.
- Start your pilot – Contact your AWS account team for a tailored briefing.
About TGS
TGS is a global provider of advanced energy data and intelligence, supporting companies across the entire energy value chain. With headquarters in Oslo, Norway, and Houston, Texas, and nearly 2,000 employees worldwide, we operate key offices in the UK, Egypt, Canada, Brazil, Malaysia, and Australia. TGS is the world’s leading provider of Ocean Bottom Node (OBN) and GeoStreamer acquisition. Our advanced imaging technologies, high-performance computing, and cloud-based data solutions help customers make confident, data-driven decisions.


