AWS Public Sector Blog

Reducing documentation drift with Amazon Bedrock AgentCore

Reducing documentation drift with Amazon Bedrock AgentCore

Documentation that drifts out of sync with code is one of the most persistent problems in software development. AI offers a path to solve it at scale. Studies show that documentation is updated 5.7–25 times less frequently than source code, and the consequences are significant: Developers lose more than 8 hours per week to inefficiencies, with insufficient documentation ranked as the second-largest cause after technical debt.

For a company with 1,000 developers, that translates to an estimated $18.5 million lost each year. Yet the payoff from investing in documentation is clear: When Stripe prioritized their developer documentation, they saw a 25 percent increase in API adoption and a 14 percent reduction in support tickets within a single quarter.

To address this challenge, Amazon Web Services (AWS) Advanced Partner Corley built an agentic solution for Eutelsat, one of the largest satellite communications operators globally, that automatically synchronizes technical documentation with the source code of in-house projects.

Agentic approach

The solution uses an agent to maintain project documentation for a given source code project. The high-level architecture involves five key interactions:

  1. The domain expert populates the knowledge base with domain-specific documentation. The purpose of the knowledge base is to provide a domain-specific context to the agent so the agent generates documentation in natural language using terminology specific to the domain. (In this case, it’s specific to aerospace and satellite operations.) It’s important to understand that the knowledge base documents and the project documentation, which we maintain with the solution using the agent, are not the same.
  2. The user, who is responsible for the maintenance of the project documentation, invokes the agent and instructs it to analyze specific code repositories and documentation associated with them.
  3. The agent reads the project source code.
  4. The agent fetches relevant documents from the knowledge base and builds a context for project documentation generation. The agent determines document relevance based on a metric reflecting similarity between the source code and the documents stored in the knowledge base.
  5. The agent fetches the existing project documentation, which is possibly outdated. The agent analyzes both the source code and the project documentation. Based on the context built in step 4, it generates an update for the project documentation using the source code as the single source of truth if the respective project documentation is missing or contradicts the source code.

This process is illustrated in the following diagram:

High-level architecture showing the interactions between the domain expert, user, agent, knowledge base, and source code repositories that enable automated documentation synchronization

Figure 1: High-level architecture showing the interactions between the domain expert, user, agent, knowledge base, and source code repositories that enable automated documentation synchronization

Solution on AWS

The architecture diagram in Figure 2 depicts the implementation built by Corley for Eutelsat. Steps 1–4 describe the knowledge base maintenance flow, while steps 5–9 describe the operational flow of the documentation synchronization agent:

AWS implementation architecture depicting the knowledge base maintenance flow (steps 1–4) and the documentation synchronization agent operational flow (steps 5–9), built with Amazon S3, Amazon Bedrock AgentCore, and Model Context Protocol (MCP)

Figure 2: AWS implementation architecture depicting the knowledge base maintenance flow (steps 1–4) and the documentation synchronization agent operational flow (steps 5–9), built with Amazon S3, Amazon Bedrock AgentCore, and Model Context Protocol (MCP)

The following steps describe each numbered interaction in the architecture illustrated in Figure 2:

  1. The domain expert uploads relevant documentation describing the infrastructure in Markdown format into an Amazon Simple Storage Service (Amazon S3) bucket. The documentation is high-level and used to teach the agent the domain context and the domain language.
  2. Amazon EventBridge Scheduler invokes an AWS Lambda function to sync (ingest) the documentation from the Amazon S3 bucket into Amazon S3 Vectors following the ingestion schedule. (This is normally once a day because this documentation doesn’t change frequently.)
  3. The AWS Lambda function triggers ingestion of the documentation from the Amazon S3 bucket into Amazon S3 Vectors using the Amazon Bedrock agent API.
  4. The Amazon Bedrock agent API ingests the documentation from the Amazon S3 bucket into Amazon S3 Vectors. After the ingestion is done, the Amazon Bedrock knowledge base is ready for use by the documentation synchronization agent.
  5. Using a purpose-built chat web application, the user asks the documentation synchronization agent to synchronize documentation for one or several code repositories, providing the repositories’ URLs.
  6. If it’s a first agent invocation, Amazon Bedrock AgentCore Runtime pulls the documentation synchronization agent’s Docker image from the Amazon Elastic Container Registry (Amazon ECR) and launches the agent. The agent is based on the Strands Agents framework.
  7. The agent reads source code of the repositories specified in the user prompt, using GitLab Model Context Protocol (MCP) server. The Amazon Bedrock AgentCore Gateway exposes the MCP server to the agent. Amazon Bedrock AgentCore hosts the MCP server, which is provisioned using Amazon ECR.
  8. Based on the source code content, the agent fetches relevant documentation from the Amazon Bedrock knowledge base using the Retrieve API to learn the domain language and the possible relations and dependencies between the systems implemented in the source code repositories.
  9. The agent reads existing project documentation hosted in Atlassian Confluence for each repository using a managed Atlassian MCP server using Amazon Bedrock AgentCore Gateway. The agent uses the context built in step 8 and the source code from the repositories as the single source of truth to update or create the project documentation in Atlassian Confluence while also using the Atlassian MCP server.

Results

To assess the value of the solution, Eutelsat and Corley ran the solution with 30 Eutelsat repositories that had no documentation. The following table summarizes the key outcomes:

Metric Value
Agent execution time (includes code and documentation analysis and documentation update and publishing) ~15–20 minutes per repository
Human review (verifying agent output) ~1–2 hours per repository for documentation generated from scratch
Processing time for 30 repositories ~1 calendar week (includes agent runtime plus human review)
AWS cost A few dollars per repository
Estimated time saved compared to fully manual approach >90%

For comparison, manual documentation creation for a medium-complexity repository takes a senior engineer 1–3 person-days. Extrapolated across the estate, that’s 30–90 person-days.

Another important result is that the solution maps relationships across repositories (based on the documentation and analysis of source code), producing an estate-wide cross-linked view that manual work wouldn’t have attempted.

Customer perspective

Alessandro Fustini, the head of software engineering at Skylogic, a Eutelsat Group company, had the following to say about the solution:

“Without documentation, a piece of software might as well not exist! This has become increasingly evident to me, and increasingly necessary, as the complexity and number of the developments my team handles keep growing.

Developers would love to be able to point at a bunch of lines of code and ask, ‘Can you tell me what you do and how?’ And this need comes not only from technical people, but also from business teams who want to understand what a service does and how it can be sold.

Another crucial point, beyond the vertical documentation process for a single service, is the ability to find connections with other services—a cross-linked documentation that gives us an aggregated logical documentation model.

Both of these have become a reality with AI. After various attempts at different points in time, the technology has now matured enough to help us with these tasks. Today, building and using a custom RAG lets us quickly generate a service’s documentation and—another nice problem we’ve solved—keep it up to date.”

An approach for software organizations

Although this solution was built for a satellite communications operator, the underlying problem of documentation that drifts out of sync with code is universal. Most organizations that develop software face it, regardless of industry.

The pattern described here—agentic code analysis, domain-aware generation using Retrieval Augmented Generation (RAG), and automated publishing with human-in-the-loop review—is industry-agnostic. The domain-specific knowledge base can be populated with terminology and standards from sectors including financial services, healthcare, manufacturing, automotive, retail, and more. The MCP-based integrations to source control and documentation tools (GitLab, Confluence) are standard across organizations.

If your engineering teams are spending weeks writing documentation that goes stale within months (or more commonly, not writing it at all), consider adopting this agentic approach. To get started, explore Amazon Bedrock AgentCore and the open source Strands Agents framework.

Alessandro Fustini

Alessandro Fustini

Alessandro Fustini is the head of software engineering at Skylogic, a Eutelsat Group company, where he leads development and DevOps teams focused on microservices architecture, satellite communications platform development, and automation on-premise, cloud, and hybrid infrastructure. With over 35 years of experience in software development, team tech leadership, and scalable architecture design, he drives adoption of modernized development flows and tools for satellite-based connectivity solutions. He is passionate about Java, databases, and R&D, and enjoys sharing "well done tech pills culture" in the tech teams.

Oleg Grytsynevych

Oleg Grytsynevych

Oleg is a senior solutions architect on the aerospace and satellite team at Amazon Web Services (AWS). Oleg has a software development background and helps aerospace customers grow and accelerate their businesses with the help of cloud technologies.

Walter Dal Mut

Walter Dal Mut

Walter Dal Mut is the chief technology officer and co-founder of Corley, a consulting company that is focused 100 percent on Amazon Web Services (AWS) and an AWS Advanced Partner. He works across cloud architecture; security, data, AI and machine learning (AI/ML); and internet of things (IoT) helping enterprise and industrial customers design and build cloud-based solutions on AWS. With a background in electronic engineering and an MBA, he combines technical expertise with a strong business perspective, with a particular focus on manufacturing and industrial innovation. Outside of work he's a maker at heart, spending his time on 3D printing, embedded electronics, and running Linux on unlikely hardware.