Scaling content review operations with multi-agent workflow

by
0 comments
Scaling content review operations with multi-agent workflow

Enterprises manage ever-growing volumes of content — product catalogs, support articles, knowledge bases, technical documentation — and keeping that information accurate, relevant, and aligned with current business facts is a persistent challenge. Manual content review is slow, expensive, and rarely keeps pace with dynamic business needs. Consulting research from firms such as McKinsey and Deloitte has repeatedly found that generative AI can deliver substantial productivity gains on knowledge tasks like content review and quality assurance, while helping organizations maintain accuracy and reduce operational risk.

A recent AWS Machine Learning Blog post shows what this looks like in practice: a content review system built with Amazon Bedrock AgentCore — purpose-built infrastructure for deploying and operating AI agents at scale — and Strands Agents, an open-source SDK for building them. The approach uses specialized agents working together so that human experts can focus on strategic review while the agent system handles large-scale verification. The pattern applies to any enterprise content type, from product documentation and knowledge bases to marketing materials and technical specifications; the walkthrough uses technical blog posts as its practical example.

Solution overview: a three-agent pipeline

The solution implements a multi-agent workflow pattern in which three specialized agents, built with Strands Agents and deployed on Bedrock AgentCore, operate as a coordinated pipeline. Each agent receives the previous agent’s output, processes it according to its role, and passes enriched information onward, creating progressive refinement:

  • Content scanner agent — analyzes raw content and extracts relevant, time-sensitive information
  • Content verification agent — validates extracted elements against authoritative sources
  • Recommendation agent — turns validation findings into actionable content updates

Splitting the work across focused agents reflects how error-prone manual scanning, verifying, and updating tends to be: the scanner identifies elements likely to age, the verifier checks current accuracy, and the recommendation agent produces precise updates. The modular design, with clear interfaces and responsibilities, makes it straightforward to add agents or expand capabilities as content complexity grows. Broader coordination patterns of this kind are discussed in this overview of multi-agent orchestration.

Practical example: reviewing technical blog content

Technology companies publish blog posts describing features, updates, and best practices — but rapid product evolution means details go stale across hundreds or thousands of published posts. In the example implementation, users trigger the system manually or on a schedule. The workflow begins when a blog URL is passed to the scanner agent, which retrieves the content using the Strands http_request tool and extracts key technical claims requiring verification. The verification agent then queries the AWS Documentation MCP Server to fetch current documentation and check each claim. Finally, the recommendation agent synthesizes findings into a review report with actionable recommendations. The sample code is open source and hosted on GitHub.

Inside the multi-agent workflow

Content scanner agent: extraction for obsolescence detection

The scanner is the entry point, responsible for identifying potentially outdated technical information. It specifically targets elements likely to age over time and produces structured output categorizing each technical element by type, location, and time-sensitivity — a format the verification agent can process efficiently.

Content verification agent: evidence-based validation

The verification agent receives the structured elements and validates them against authoritative sources via the AWS Documentation MCP Server, guided by objective, measurable criteria:

  • Version-specific information: does the mentioned version number, API endpoint, or configuration parameter still exist?
  • Feature availability: is the described capability still offered in the specified regions or tiers?
  • Syntax accuracy: do code examples, CLI commands, and configuration snippets match current documentation?
  • Prerequisite validity: are listed requirements, dependencies, and setup steps still accurate?
  • Pricing and limits: do stated costs, quotas, and service limits align with current published information?

For each element, the agent generates targeted search queries based on element type, queries the documentation server, and compares the original claim against official sources. Each result is classified as CURRENT, PARTIALLY_OBSOLETE, or FULLY_OBSOLETE, and specific discrepancies are documented with evidence.

An example: when the scanner identifies the claim “Amazon Bedrock is available only in us-east-1 and us-west-2 regions,” the verification agent generates the query “Amazon Bedrock available regions,” retrieves current availability from AWS documentation, finds the service available in additional regions including eu-west-1 and ap-southeast-1, and classifies the claim as PARTIALLY_OBSOLETE with evidence citing the expanded region list as of the verification date. The verifier’s output preserves the scanner’s element structure while adding classifications and evidence.

Recommendation agent: actionable updates

The final agent transforms validation findings into content updates ready for implementation, generating specific recommendations that preserve the original content’s style while correcting technical inaccuracies.

Adapting the pattern to other content review use cases

The three-agent sequential workflow adapts to other review scenarios without architectural changes — product documentation, marketing materials, or regulatory compliance documents alike. Adaptation means modifying each agent’s system prompts to focus on domain-specific elements and swapping tools or knowledge sources. Where the blog example uses an http_request tool to fetch content and the AWS Documentation MCP Server for validation, a product-catalog reviewer might use database connector tools and inventory-management APIs; a compliance reviewer would prompt the scanner for regulatory statements, point the verifier at legal databases, and configure the recommendation agent to produce audit-ready reports.

The suggested modifications: replace the values of the CONTENT_SCANNER_PROMPT, CONTENT_VERIFICATION_PROMPT, and RECOMMENDATION_PROMPT variables with custom prompt instructions:

  python
  CONTENT_SCANNER_PROMPT = """"""
  CONTENT_VERIFICATION_PROMPT = """"""
  RECOMMENDATION_PROMPT = """"""

Update the MCP server used by the content verification agent to the authoritative documentation source for the domain:

  python
   product_db_mcp_client = MCPClient(
       lambda: stdio_client(StdioServerParameters(
           command="uvx", args=("")
       ))
   )

And add appropriate content-access tools, such as database_query_tool and cms_api_tool, to the content scanner agent where the http_request tool is insufficient:

python
   scanner_agent = Agent(
       model="us.anthropic.claude-3-7-sonnet-20250219-v1:0",
       system_prompt=CONTENT_SCANNER_PROMPT,
       tools=(database_query_tool, cms_api_tool)  # Replace http_request
   )

These targeted changes let the same architecture handle any content type while keeping the proven three-agent structure and core orchestration logic intact.

Limitations and what to watch

  • An AI verification pipeline is only as reliable as its authoritative sources; stale or incomplete documentation propagates errors into “verified” results.
  • Agents can misclassify claims — especially nuanced ones — so human review of recommendations remains important before publishing changes, particularly for compliance content. Reasons such projects stall in practice are covered in this piece on agent project governance.
  • Productivity estimates from consulting studies are directional, not guarantees; actual gains depend on content volume, domain complexity, and how much human oversight the workflow retains.
  • Running scheduled multi-agent reviews at scale has real inference costs that should be modeled against the cost of manual review.

Conclusion

The post demonstrates an AI-driven content review system built on Amazon Bedrock AgentCore and Strands Agents: a multi-agent workflow in which specialized agents scan content, verify technical accuracy against authoritative sources, and generate actionable recommendations — with a clear path to adapting the same pattern to other content domains by changing prompts, tools, and data sources. A sensible starting point is a pilot on a subset of content, custom prompts for the specific domain, and verification sources appropriate to the use case, refining each agent iteratively.

About the authors of the original solution

Sarath Krishnan is a Senior Generative AI/ML Specialist Solutions Architect at Amazon Web Services, helping enterprise customers design and deploy generative AI and machine learning solutions, with expertise in MLOps and production-ready AI systems.

Santosh Kuriakose is an AI/ML Specialist Solutions Architect at Amazon Web Services, applying AI and ML expertise to technology solutions that deliver strategic business outcomes.

Ravi Vijayan is a Customer Solutions Manager at Amazon Web Services with a background as a developer, technical program manager, and client partner, focused on cloud migration and generative AI modernization.

Related Articles