Self Learning and Growing Agents

Turns raw evidence into reusable understanding.

Start from a seed corpus, generate better questions, gather and rank evidence, remember both facts and gaps, and emit outputs that humans, maps, and deeper service views can all reuse.

Seed Corpus starter sources Fact Memory durable facts and gaps Interaction View render-ready graph output
Circular self-learning loop reference illustration

1. Problem Statement

Teams already have the knowledge they need, but it is scattered, uneven in trust, and expensive to reuse.

The answers are usually somewhere in code, docs, runbooks, and operational history. But because those sources are fragmented and differently trustworthy, humans and agents keep rediscovering the same answers from scratch.

Fragmented onboarding and system knowledge starting point Questions arrive fast No single home what changed who calls what Docs and runbooks Useful, but uneven service pages runbooks older design notes Live repos and config Truth, harder access clients and handlers CDK and AppConfig Snapshots and one-offs Poor reuse manual notes, tribal knowledge throwaway summaries Before canonicalization The same answers kept being rediscovered. No stable shared memory. No durable structured export. No cheap path to reuse. ? ? ?
Fragments were real knowledge.

They just were not arranged as a repeatable product.

Trust was uneven.

Live code and config often answered questions better than docs, but were harder to reuse quickly.

Rediscovery was expensive.

Without a canonical memory, people and agents repeated the same investigation over and over.

2. Solution / How The Pipeline Works

The repo works as one operational system with clear boundaries between learning, curation, export, and consumption.

The important story here is not a stage list. It is the operational split: orchestration on top, local KB layers in the middle, reusable rendering and query consumers downstream, and optional AWS publish kept separate from the local loop.

Operational architecture of the local knowledge pipeline and downstream consumers Operational story Orchestration layer Agent specs SOPs Scripts Local knowledge boundary snapshots raw captured evidence knowledge store.json facts, gaps, provenance curated readable facts and gap lists export stable JSON handoff render maps and boards Each layer has one job, so humans, agents, renderers, and publishing do not trample each other. Consumer side query_kb.py local KB queries Local users CLI and review flow External agents MeshClaw, Claude, others Optional publish KB slices exported payloads Bedrock personal KB Validation: tests, schema and pack checks, stable exporter payloads. Rendering kits: shared HTML/CSS/JS shells for maps and service boards.

What stays local

Snapshots keep raw source captures. knowledge/store.json is canonical memory. Curated outputs are readable summaries. Exported views and published KB slices are downstream products, not the source of truth.

How consumers attach

query_kb.py is the local query adapter. The same curated/export contracts also let an external consumer such as MeshClaw or Claude attach without re-learning the corpus from zero.

Why maps and boards are reusable

The renderer kits are shared shells: typed JSON payloads feed common HTML/CSS/JS behavior for nodes, edges, labels, selection, evidence, and side panels instead of hand-drawing each page.

What keeps it honest

Validation sits under the whole repo: tests, schema checks, pack validation, and exporter contracts keep the KB and rendered outputs reusable instead of drifting into one-off artifacts.

3. How It Learns

The loop starts from the starter corpus and gets better by revisiting what it cannot prove.

The system asks follow-up questions, stores facts when it can prove them, stores gaps when it cannot, and later retries the unresolved set.

Manifest-first self-improvement loop Base input seed manifest seed docs, parent-child paths, follow-on hints Frontier memory What should we learn next? 1. Ask generate concrete next question 2. Gather mine code, docs, config rank sources 3a. Store fact lesson, service, edge, evidence 3b. Store gap hard wall, ambiguity, next target 4. Revisit later retry after new evidence lands

Asks itself questions

The frontier is built from weak nodes, weak edges, image gaps, unresolved items, and new discoveries.

Stores facts

When something is grounded, it becomes a reusable fact, lesson, normalized service, or typed edge.

Stores gaps honestly

When something is not provable yet, it stays a gap instead of being flattened into fake certainty.

Revisits unresolved areas

Open gaps survive across cycles, so later evidence can close them without restarting from zero.

4. Conflict Handling

When sources disagree, stronger evidence wins and unresolved conflict stays visible.

The system does not pretend uncertainty away. It records confidence and preserves disagreement when a proof path is still missing.

Source ranking and conflict handling Highest trust 1. Live code and config handlers, clients, schemas, CDK, AppConfig Then 2. Active repos and current runbooks Then 3. Wiki and design context Lowest trust 4. Older snapshots and stale notes If sources conflict prefer the stronger source If still unclear store both and mark a gap

Simple rule

If code says one thing and a wiki says another, code wins unless there is a clearly stated reason not to.

Why this matters

The maps and boards stay trustworthy because the KB carries evidence and confidence, not just conclusions.

5. What The Outputs Become

These outputs are structured views: they define typed things, labeled relationships, and the side panels that explain them.

The map view and the AWS component board are not hand-built diagrams. Each one is a typed payload plus a shared HTML/CSS/JS shell: nodes, edges, line labels, panel fields, and view behavior all come from a stable render contract.

Structured view contracts for system interaction maps and AWS component boards Shared export idea Structured payloads drive both views. Stable data contracts plus shared HTML, CSS, and JS. System interaction map Typed services + typed edges Main canvas edge label typed service nodes line labels for ops and contracts Side panel summary evidence gaps confidence view shell base template, CSS, JS, selection AWS component board Typed components + labeled paths Main board typed AWS/runtime nodes path labels for read, write, and async flows Side panel purpose resources evidence open notes board shell base template, CSS, JS, side panel

6. Where We Landed

The payoff is a local KB plus a map-ready org interaction layer with grounded edges.

The current export carries 83 normalized services and 100 grounded edges, enough to show real billing and invoicing pathways rather than a vague org chart.

Billing and invoicing interaction map slice with grounded operations Canonical system-interaction export Billing + Invoicing service map AIM to invoice delivery, with grounded edge labels. Upstream inputs Billing core Invoice path Consumers and controls account inputs bill line items invoice payload commitStatement GatherComplianceData SendInvoicingEmail commitStatement InvoiceEmailQueueEntry GetEligibleFX GetRate GetPurchaseOrderIds GetOfflineRemitInfo AIM Account input manager BillComp / BCA Billing compute core LIDS Line item source of truth IO Invoice orchestration InCa Invoice computation flow BOSS Bill closed event source IM Invoice Manager Khipus Statement source IAGS Artifact generation Basilisk Dagger output producer SCS Statement compliance TIMS Tax invoice metadata TNS Notification service PEM Bill close trigger sink ESJ Rendered email handoff Policy gateway Payment policy service FX service Rate lookup provider POTS PO identifier source Legend sync operation event or async handoff data contract

Canonical KB

knowledge/store.json now holds 4,005 facts, 10 tracked gaps, and 734 touched sources.

481 live code sources 26 active repos 116 ops docs

Feed

curated/billing-invoicing-org-interactions-feed.json holds normalized services, typed edges, evidence, and confidence.

Render payload

curated/system-interaction-map-views/billing-invoicing-org.json holds lane placement, summaries, and export-ready node ids.

Grounded labels

This slice already carries concrete labels like commitStatement, GetEligibleFX, GetRate, SendInvoicingEmail, and GetOfflineRemitInfo.

Demo
Q and A theme illustration