Field Kit: A Self-Organizing Consulting OS

Purpose: Track and analyze emerging signals in AI, sustainability, and policy. Monitor academic research. Track regulatory developments. Synthesize patterns across domains.

Data: 267 trend signals, 216 academic papers, 10 regulatory provisions. Automated ingestion via GitHub Actions. Manual curation from client work and newsletters.

Purpose: RAG over consulting IP — frameworks, case studies, and methods. Proprietary knowledge that compounds over time.

Purpose: Brand intelligence and competitive analysis. Merged from a standalone multi-agent market research tool into the Field Kit ecosystem, enabling unified semantic search across all knowledge domains.

Purpose: Mobile-first access to the full knowledge system. A Claude Sonnet-powered conversational agent with an MCP bridge that routes queries to all four servers. Supports Swedish and English, maintains per-user conversation history, and runs agentic tool-use loops (up to 10 iterations per query).

The same four servers run in three places, all sharing a single Supabase corpus: stdio locally for Claude Desktop and Claude Code, a Hetzner VPS running the Docker Compose stack (SSE endpoints on ports 8081-8084 with health checks) plus the Telegram bot, and a Mac mini running the MCP servers for an autonomous research agent. Add a signal from any surface and it is queryable from every other surface seconds later.

Purpose: Organization canonicalization across the whole corpus. Brands, cases, and reports all reference organizations — org_registry keeps one canonical record per org with aliases, so “Uppsala University” and “Uppsala universitet” resolve to the same entity instead of fragmenting the knowledge graph.

Every Sunday at 04:00 UTC, while I sleep, a GitHub Actions workflow runs the loop: benchmark the agent against 20 held-out consulting questions → run a generative probe that synthesizes ~10 fresh questions from the week’s ingestion → decay old co-citation edges → find hot connected components and have a small model name them as dreamed clusters → write everything into a Dream Review queue.

Dreamed clusters are not facts — they are weak proposals until reviewed. The Dream Review queue is where I accept, dismiss, or promote them. Two heavier dreams (memory consolidation and agent-prompt revision) run manually and always require a human-reviewed diff before applying.

The paper firehose is allowed to stay large — 2,800+ papers and growing daily. Bundles are the layer that says what counts: curated groups with a title, a rationale, member roles, and a review status. A dreamed cluster with strong evidence gets promoted into a bundle; a bundle is something I can hand to a client conversation. Curation on top of the firehose, not instead of it.

A 20-question held-out benchmark with weighted rubrics tests the agent end-to-end against the live KB. Scored traces are what drive the quality gate: only answers above threshold increment usage counters and reinforce co-citation edges. The same scores feed the instruction dream, which proposes the next version of the agent prompt from low-scoring traces. Quality measurement isn’t a report — it’s the system’s feedback signal.

Without Field Kit (old way): Google “edge AI research 2024” → sift through blog posts and vendor marketing → search Google Scholar → read 5-6 abstracts → synthesize manually. Time: 30-45 minutes.

With Field Kit (new way): search_trends("edge AI deployment", threshold=0.4) → 8 relevant signals → search_papers("edge AI efficiency") → 5 academic papers with citation counts → connect_signals([...]) → AI synthesis. Time: 3-4 minutes.

Result: Better answer (academic + trend signals + synthesis), 10x faster, with source citations ready for slides.

Context: Notice similar challenges across 3 different clients — all struggling with internal AI governance, no clear decision-making framework for AI tool adoption.

Action: add_trend() with title “Enterprise AI Governance Vacuum”, analysis of pattern, strength “accelerating”, category “policy”.

Future value: Next client with similar challenge → search finds this pattern → reference 3 past cases → faster diagnosis, better recommendations. Compound returns in action.

Building for your own acute pain point produces better products than building for hypothetical users. You use it daily, notice every friction point, iterate immediately. No user interviews needed - you ARE the user. The tunable search threshold (0.3-0.6) came from real frustration: “Sometimes I want broad discovery, sometimes I want exact matches. Why force me to choose one?”

MCP servers eliminate the “build a UI” bottleneck for internal tools. Before MCP: Build backend → Build API → Build web UI → Deploy → Maintain. With MCP: Build backend → Build MCP server → Use in Claude Desktop. Iteration speed: 10x faster. When you DO want a web UI, the MCP server becomes your API. Nothing wasted.

Cost to embed 1000 items: $0.01. Time to manually tag and organize 1000 items: 20+ hours. Conclusion: Don’t optimize for embedding cost. Optimize for capture friction. Field Kit approach: Embed everything, search semantically. No folders, no tags.

Semantic search finds related items. That’s retrieval. Pattern detection finds meta-trends across items. That requires reasoning. Solution: connect_signals uses Claude Sonnet to analyze 2-5 signals together and synthesize common themes, implications, and strategic opportunities. You pick the signals, AI finds the patterns.

Week 1: 20 signals, minor usefulness. Month 2: a few hundred signals and papers, frequently helpful. Today: 10,052 items across eight content types, with automated ingestion adding dozens daily. The curve is exponential, not linear. The catch: past a few thousand items, growth alone stops being the interesting part.

Once the corpus outgrew what one person can hold in their head, the bottleneck shifted from capture to sensemaking. The answer wasn’t a bigger search box — it was giving the system a between-session life: counters that record what gets used, a co-citation graph that records what gets used together, and a weekly dreaming loop that names the patterns. Two design rules made it safe: gate every feedback signal on answer quality (popularity is not truth), and treat everything the system dreams up as a proposal until a human accepts it.

Every edge in the graph should show the reason it exists: which AskBox thread cited both entries, which dream probe reinforced the pair, which bundle membership connects the evidence. Provenance for connections, not just nodes.

Clicking an AskBox thread highlights the retrieved and cited nodes in the graph — making actual use visible, not just archive structure.

A weekly view of new clusters, repeated questions, unbundled high-use papers, stale dream items, and emerging contradictions — the organism’s pulse, readable at a glance.

Turn exploration into next actions: review this dreamed cluster, promote this bundle, write a field note, archive this noisy source, mark this edge as useful or noise.