AI-Powered Multi-Agent Platform for Blockchain Operations and Log Analysis

ripple · Finance · 2024 · source Agentic: yes · promotional bias: low · source-backed · extracted with prompt 0.5.4 (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: Blockchain network operations and log/code analysis

Ripple needed platform engineers to troubleshoot XRPL production issues without spending days manually correlating massive peer-to-peer blockchain logs with C++ protocol code and without relying on a small pool of C++ experts for every incident.

Constraints:

• XRPL is decentralized and globally distributed, with different node types and noisy peer-to-peer logs
• single log loads can be tens of gigabytes and log lines may be out of sequence
• answers require correlating operational logs with code and protocol concepts
• platform engineers need natural-language access rather than direct C++ expertise
• agent outputs need prompt guardrails, observability, and production runtime support
• log and code preprocessing must be refreshed continuously

Architecture

Ripple built a multi-agent operations platform on AWS. Log pipelines bring validator, hub, and client-handler logs into S3, chunk them with boundary-aware Lambda processing, push work through SQS, and load parsed log metadata into CloudWatch. Code and standards repositories are periodically retrieved, versioned, stored in S3, embedded with Titan Text Embeddings V2, and indexed in Neptune Analytics for GraphRAG over code relationships. A web UI sends engineer questions through API Gateway and Cognito to an orchestrator agent. The orchestrator classifies intent, invokes specialist code-analysis and log-analysis agents, and synthesizes results. The log-analysis agent works with a query-generator agent to produce CloudWatch Logs Insights queries. Agents run across Lambda and Bedrock AgentCore Runtime with DynamoDB state, Secrets Manager, SSM configuration, prompt guardrails, and observability.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  web-chat-ui["web-chat-ui"] --> api-gateway["api-gateway"]
  api-gateway --> cognito-auth["cognito-auth"]
  api-gateway --> orchestrator-agent["orchestrator-agent"]
  orchestrator-agent --> dynamodb-state["dynamodb-state"]
  orchestrator-agent --> code-analysis-agent["code-analysis-agent"]
  orchestrator-agent --> log-analysis-agent["log-analysis-agent"]
  log-analysis-agent --> query-generator-agent["query-generator-agent"]
  query-generator-agent --> cloudwatch-logs["cloudwatch-logs"]
  log-analysis-agent --> cloudwatch-logs
  code-analysis-agent --> neptune-graphrag-store["neptune-graphrag-store"]
  log-ingestion-s3["log-ingestion-s3"] --> log-chunking-lambda["log-chunking-lambda"]
  log-chunking-lambda --> sqs-log-work["sqs-log-work"]
  sqs-log-work --> log-processor-lambda["log-processor-lambda"]
  log-processor-lambda --> cloudwatch-logs
  code-retrieval-pipeline["code-retrieval-pipeline"] --> code-docs-s3["code-docs-s3"]
  code-docs-s3 --> neptune-graphrag-store

Components

Data flow

Raw XRPL node logs are copied into S3, chunked by an S3-triggered Lambda while preserving log-line boundaries, placed onto SQS, then processed into CloudWatch. Code and documentation are retrieved from repositories, stored in S3, chunked, embedded, and loaded into a Neptune Analytics GraphRAG store. An engineer asks a question through the web UI. API Gateway and Cognito authenticate the request. The orchestrator agent classifies intent and calls code-analysis and/or log-analysis agents. Code analysis retrieves graph-grounded code context; log analysis asks the query-generator agent for a valid CloudWatch query, runs it, and returns relevant logs. The orchestrator synthesizes a single response.

Why this architecture

Ripple needed to correlate code relationships and noisy operational logs, so the system separates code and log pipelines while letting agents collaborate at query time. GraphRAG was chosen over a plain vector store because code understanding depends on relationships across files and documentation. A query-generator agent isolates CloudWatch query correctness from higher-level log reasoning. AgentCore and Lambda split runtime responsibilities while DynamoDB, Secrets Manager, SSM, prompt guardrails, and observability handle state, configuration, credentials, behavior constraints, and performance monitoring.

Models used: Amazon Bedrock · Titan Text Embeddings V2 · Cohere Rerank · Strands SDK · Amazon Bedrock AgentCore Runtime

Scale

• XRPL has almost 900 plus nodes distributed globally.
  “We have almost 900 plus nodes exist.”transcript, stated

  “The 900 nodes I talk about, it's located throughout the world, starting from Japan to end in San Francisco”transcript, stated
• XRPL recently closed 100 million ledgers over 13 years, with three-to-five-second finality.
  “we recently closed 100 million ledgers in the last 13 years. That also talks about the three to five seconds finality.”transcript, stated
• A single log load is roughly 35 to 50 GB, and more than 40 mainnet nodes produce about 2.5 TB of data.
  “huge volume of log, which is almost 35 to 50 gigs for a single load, and Ripple almost operates like, 40 plus mainnet, that constitutes around two and a half terabytes of data.”transcript, stated
• Manual investigation previously took about two to three days for a platform engineer plus C++ expert.
  “that used to take at least two to three days for a platform engineer, working with the core C++ engineer, to have a meaningful summary out of it.”transcript, stated
• Consensus rounds happen every three to four seconds, requiring multi-line log correlation.
  “In XRPL, we have something called consensus rounds, which happen every three to four seconds, and that's a sequence of events that happen for each and every phase.”transcript, stated

Alternatives considered (roads not taken)

Manual log and code correlation by platform and C++ experts

Rejected because: It could take days and created a bidirectional dependency between platform engineers and protocol specialists.

Plain OpenSearch vector store for code retrieval

Rejected because: Ripple needed GraphRAG to preserve codebase relationships.

A machine-learning system trained directly on data

Rejected because: The team shifted toward AI agents that correlate logs and code in natural language rather than a conventional ML inference setup.

One generalist agent for every task

Rejected because: The platform separates orchestration, code analysis, log analysis, and query generation so each agent has a focused responsibility.

Patterns

multi-agent-orchestration (orchestration)

Ripple uses an orchestrator plus specialist code-analysis, log-analysis, and query-generator agents, with the orchestrator selecting sequential or parallel execution.

rag-retrieval (retrieval)

The code-analysis agent retrieves code and documentation context from a Bedrock knowledge base backed by GraphRAG.

retrieval-ranking (retrieval)

A reranking layer performs a second relevance pass over retrieved GraphRAG documents.

tool-use-orchestration (orchestration)

The log-analysis agent delegates CloudWatch query construction to a query-generator agent using a static JSON tool.

observability-tracing (operations)

AgentCore observability tracks sessions, latency, duration, token usage, and errors for agent performance improvement.

guardrails-io-filtering (governance)

Ripple uses explicit per-agent prompt guardrails that define each role, task, and prohibited behavior.

Tradeoffs

Use GraphRAG for code understanding.

Chose Neptune Analytics GraphRAG over a plain OpenSearch vector store over OpenSearch vector store.

Rationale: Code questions depend on relationships across files and entities, not just semantic similarity.

Split query generation from log analysis.

Chose dedicated query-generator agent over having the log-analysis agent write every query directly.

Rationale: Logs Insights syntax accuracy is important enough to isolate as a specialist responsibility.

Use both Lambda and AgentCore for agent hosting.

Chose mixed Lambda and Bedrock AgentCore Runtime deployment over migrating every agent immediately.

Rationale: Lambda met constraints when AgentCore was still new, while AgentCore offered purpose-built production agent runtime as it matured.

Preprocess logs daily instead of querying raw files ad hoc.

Chose S3/SQS/Lambda/CloudWatch log-processing pipeline over manual raw-log inspection.

Rationale: The volume is too large for manual investigation and needs prepared, searchable operational data.

Gotchas (what bit them)

Peer-to-peer blockchain logs are noisy and out of sequence.

Root cause: XRPL has decentralized node types and consensus phases whose meaningful events are spread across many log lines.

Resolution: Use code-analysis context plus log-analysis queries so multiple log lines can be collated into a protocol-aware answer.

Manual incident diagnosis depended on C++ protocol experts.

Root cause: Platform engineers needed C++ codebase knowledge to interpret logs and determine whether something was an issue.

Resolution: Correlate logs and code through the agent platform so platform engineers can get meaningful summaries directly.

CloudWatch query syntax is a specialized subproblem.

Root cause: The log-analysis agent needs syntactically accurate Logs Insights queries before it can answer operational questions.

Resolution: Create a dedicated query-generator agent whose only job is accurate query generation.

Agent infrastructure can distract from business logic.

Root cause: Running production agents requires runtime, communication, credentials, configuration, and observability capabilities.

Resolution: Use Bedrock AgentCore Runtime, Secrets Manager, SSM Parameter Store, and AgentCore observability to offload infrastructure concerns.

Evaluation

Ripple evaluated the platform through live demonstrations, observability of agent sessions and latency, and whether the assistant could answer multi-line consensus-round questions that previously required expert manual analysis.

Metrics: agent sessions · latency · duration · token usage · errors · ability to collate consensus-round log lines · time reduced from days to interactive summaries

Outcomes

• platform engineers can ask natural-language questions over code and logs
• manual two-to-three-day expert investigations are replaced by agent-generated summaries
• the system removes bidirectional dependency between platform engineers and C++ experts
• Ripple gains reusable log/code correlation infrastructure for XRPL operations

Ripple describes almost 900 plus XRPL nodes, 100 million ledgers over 13 years, three-to-five-second finality, 35-50 GB per single log load, 40 plus mainnet nodes, and around 2.5 TB of log data.