Verytis: Shared Error Memory for AI Coding Agents via MCP

yaml

title: “Verytis: Shared Error Memory for AI Coding Agents via MCP” description: “How a Model Context Protocol server turns agent coding failures into a queryable knowledge base, reducing redundant errors across sessions and teams.” pubDate: 2026-05-24T00:10:48.064086Z category: dev-tools heroImage: “https://images.unsplash.com/photo-1484417894907-623942c8ee29?auto=format&fit=crop&w=1600&q=80” sourceUrl: “https://www.verytis.com” sourceName: “verytis.com” tags:

agentic-ai
mcp
infrastructure
error-handling featured: false

Coding agents fail the same way, repeatedly. Missing environment variables, broken path aliases, stale dependency references. Each agent session rediscovers these failures independently, burning tokens and developer time. Verytis addresses this by implementing a Model Context Protocol (MCP) server that stores anonymized error contexts and ranks candidate fixes by proof-of-fix signals: tests passed, builds succeeded, verified resolution sequences.

This is not a logging service. It is a shared memory layer that sits between your agent and its code execution environment, letting it query past failures before attempting fixes.

Architecture: MCP as Error Memory Transport

Verytis uses MCP, Anthropic’s protocol for extending agent context with external data sources. The flow:

Error capture: Agent encounters a failure (build error, runtime exception, test failure).
Context serialization: Verytis extracts error message, stack trace, file paths, environment hints.
MCP query: Agent sends serialized context to Verytis MCP server.
Ranking retrieval: Server returns ranked list of similar failures with resolution metadata.
Fix application: Agent applies highest-ranked fix or uses context to guide its next action.

The MCP server exposes two primary resources:

verytis://search: Query interface for error similarity matching.
verytis://case/{id}: Detailed resolution history for a specific error case.

MCP handles authentication via OAuth tokens or API keys, depending on deployment mode (single-user vs. team). The protocol is stateless: each query is independent, no session affinity required.

State Synchronization and Concurrent Writes

When multiple agents or developers contribute error memories simultaneously, Verytis uses an append-only event log with eventual consistency:

Each resolved error becomes an immutable case entry.
New resolutions append to the case history with timestamps and proof-of-fix metadata.
Ranking algorithms favor recent, verified fixes over older or unverified ones.

No distributed locking. Conflicts are rare because error contexts are content-addressed: two identical errors map to the same case ID. If two agents resolve the same error differently, both resolutions are stored and ranked by success signals.

Proof-of-Fix Signals

Verytis does not trust self-reported fixes. It ranks candidates by observable outcomes:

Signal Type	Weight	Verification Method
Tests passed	High	CI exit code, test runner output
Build succeeded	High	Compiler/bundler exit code
No recurrence	Medium	Same error absent in next N runs
Manual confirmation	Low	Developer marked as resolved
Time since fix	Decay	Exponential decay over 30 days

This prevents the database from filling with speculative fixes that never worked. Only resolutions with measurable success propagate to other agents.

Security Boundaries and Anonymization

Error messages often leak secrets: API keys in stack traces, file paths revealing internal structure, proprietary library names. Verytis applies redaction before storage:

Environment variable values are stripped, keys are hashed.
File paths are normalized to relative paths from project root.
Stack traces are truncated to function names and line numbers.
Custom redaction rules via regex patterns in MCP server config.

Access control operates at two levels:

MCP authentication: OAuth or API key per client.
Case visibility: Public (anonymized), team-scoped, or private.

Team-scoped cases are visible only to authenticated clients in the same organization. Private cases never leave the local MCP server instance.

Deployment Shapes

Verytis supports three deployment modes:

Hosted SaaS: Verytis runs the MCP server, stores anonymized cases in a shared database. Agents connect via API key. Fastest setup, largest shared knowledge base, least control over data residency.

Self-hosted team instance: Run the MCP server in your VPC, point agents at your internal endpoint. Cases stay within your infrastructure. Requires Docker or Kubernetes, PostgreSQL for case storage.

Local-only mode: MCP server runs on developer’s machine, stores cases in SQLite. No network calls, no shared knowledge. Useful for offline work or highly sensitive codebases.

Configuration example for self-hosted:

# verytis-mcp-config.yaml
server:
  host: 0.0.0.0
  port: 8080
  auth:
    provider: oauth
    issuer: https://your-idp.example.com

storage:
  backend: postgres
  connection_string: postgresql://user:pass@db:5432/verytis
  retention_days: 90

redaction:
  patterns:
    - regex: 'sk-[a-zA-Z0-9]{48}'
      replacement: '[REDACTED_API_KEY]'
    - regex: '/Users/[^/]+/'
      replacement: '/home/user/'

ranking:
  weights:
    tests_passed: 10
    build_succeeded: 8
    no_recurrence: 5
    manual_confirmation: 2
  decay_half_life_days: 30

Observability and Failure Modes

Verytis exposes Prometheus metrics at /metrics:

verytis_queries_total: Total error queries received.
verytis_cache_hits: Cases served from in-memory cache.
verytis_ranking_latency_seconds: Time to rank and return candidates.
verytis_redaction_failures: Errors during anonymization (should be zero).

Common failure modes:

MCP server unreachable: Agent falls back to standard error handling, no shared memory. Degraded experience, not a hard failure.

Ranking timeout: If database query exceeds 2 seconds, return empty result set. Agent proceeds without historical context.

Redaction bypass: If a redaction rule fails, the entire case is dropped rather than stored with potential secrets. Logged as redaction_failures.

Stale fix recommendations: Decay weights prevent old fixes from dominating, but if your stack changes rapidly (new framework version), you may retrieve irrelevant cases. Mitigation: tag cases with dependency versions, filter by compatibility.

Integration with Existing Agent Frameworks

Verytis MCP server integrates with any agent that supports MCP clients. Examples:

LangGraph: Add Verytis as a tool node that queries before executing fixes.
Anthropic Claude with MCP: Configure Verytis as an MCP resource in Claude Desktop or API.
Custom agents: Use the MCP SDK (Python, TypeScript) to wrap Verytis queries in your orchestration logic.

No framework lock-in. MCP is transport-agnostic: works over stdio, HTTP, or WebSocket.

Technical Verdict

Use Verytis when:

Your team runs coding agents frequently and sees repeated error patterns.
You want agents to learn from each other’s failures without manual knowledge transfer.
You need proof-of-fix validation, not just speculative suggestions.
You can tolerate eventual consistency in error memory (no strong read-after-write guarantees).

Avoid Verytis when:

Your codebase changes so rapidly that historical fixes are obsolete within days.
You cannot expose any error context, even anonymized, outside your local machine.
Your agents already have access to comprehensive internal docs and runbooks that cover common failures.
You need real-time synchronization of error state across distributed agents (MCP is request-response, not pub-sub).

Verytis is infrastructure for agent memory, not agent intelligence. It reduces redundant exploration, but it does not replace good error messages, tests, or documentation. Treat it as a cache for failure knowledge, with all the usual cache invalidation challenges.