AWS for Industries

Always-on, grounded, and going agentic: How TGS built Scout on AWS Quick

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.

Scout end-to-end architecture on AWS Quick: permission-aware retrieval, citation-grounded generation, and agentic write-back to Confluence, SharePoint, and Jira

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

Line chart of Scout’s cumulative registered users and weekly active users rising over eight months

Figure 2: Scout’s user base grew organically with sustained weekly active usage

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

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.


About the authors

Elizabeth Chen

Elizabeth Chen

is a Process Automation Engineer at TGS, where she develops, administers, and supports enterprise solutions across Microsoft 365, Power Platform, and Atlassian. Her work spans process automation, application development, API-driven integrations, and reporting and analytics, with a focus on turning practical business challenges into effective solutions that deliver meaningful, measurable impact. She holds a Professional Scrum Master I certification and an M.S. in Management Information Systems from Texas A&M University.

Ali Khoja

Ali Khoja

is a Principal Customer Solutions Manager in the AWS Energy & Utilities Division, where he leads strategic relationships with Fortune 200 customers and drives digital transformation initiatives. With more than 25 years of experience, his particular strength is building trusted-advisor relationships with senior business and technology executives, helping enterprises innovate and optimize through technology and guiding them from strategy through execution. An AWS Certified AI Business Strategist and active mentor in the AWS community, he also serves as a community leader trained through United Way Project Blueprint, pairing deep enterprise acumen with a focus on measurable business results.

Fabio Santana

Fabio Santana

is a Software Support Associate at TGS and a dedicated geophysicist with a decade of industry experience, including three years as an offshore geophysicist. Trained in oceanography with a master’s in Marine Geology and Geophysics, he has worked offshore handling high-resolution geophysical data quality control, processing, initial interpretation, and client-side data validation. He brings rigorous, field-tested expertise in subsurface data quality to the technical support of geoscience software and workflows.

Hayden Faw

Hayden Faw

is a Product Manager at TGS with a background in geophysics, machine learning, and technology development. He enjoys working at the intersection of people and technology, helping teams turn complex ideas into practical solutions that make everyday work easier. His focus is on understanding the challenges people face, bringing the right people together, and developing tools that make a meaningful difference in how teams work.

Constantine Vavourakis

Constantine Vavourakis

is a senior Generative AI Architect at Amazon Web Services (AWS) and a rapid prototyper focused on generative AI applications in oil and gas. With more than 15 years in the energy sector, he works at the intersection of generative AI, cloud computing, and industrial Internet of Things (IoT) and operational technology (OT), applying new technology to challenges like emissions reduction. Driven by a strong builder mentality, he is passionate about solving hard problems with new solutions and bringing innovative prototypes quickly from concept to reality.