llm-wiki-runtime: Share Agent Knowledge, Not Context

Introduction

As AI Agent systems scale beyond isolated single-task workflows, developers encounter a fundamental pain point: valuable domain knowledge generated by one specialized Skill becomes trapped within that workflow’s private memory. When an Agent Skill is replaced or retired, the accumulated contextual data and domain insights may vanish entirely, even though the information remains useful for other downstream Agents. The llm-wiki-runtime framework addresses this challenge. It enables domain knowledge created by one Agent to be reused by other authorized Agents while enforcing a critical boundary: shared knowledge does not equal shared prompt context.

This article dissects the architecture, core design principles, implementation workflow and verified test results of llm-wiki-runtime, using a human resources (HR) candidate screening pipeline as the primary real-world case study. For engineering teams managing distributed Agent services and model endpoints, an API gateway can standardize knowledge access policies and route requests consistently, and teams building multi-Agent knowledge systems may leverage 4sapi to unify invocation pipelines across heterogeneous model and tool services.

1. Core Thesis: Knowledge Should Outlive the Skill That Produces It

We begin with a practical HR workflow example. A dedicated HR Skill executes resume screening: it extracts factual candidate information, validates identity records, matches candidate profiles against job requirements, flags risk items, and generates formal screening reports. The byproduct of this work is persistent Domain Knowledge, which is far more durable than ephemeral one-turn LLM responses displayed in conversation history.

The pain point emerges when this domain knowledge remains tightly coupled to its originating workflow. A separate candidate-detail Agent may need to parse the same resume dataset again. An interview question generation Agent may rely on candidate records and talent graphs to interpret candidate identities. Newly provisioned Agents in the future may not even detect that validated candidate archives already exist within the system. This creates two recurring failure modes:

1. Valid candidate records exist in storage, yet subsequent Agents cannot locate them.

2. Agents must load and scan excessive private datasets far beyond the scope of their assigned tasks to retrieve target information.

Simply adding a persistent directory for a Skill does not resolve the root issue. Even if data is saved, it remains bound to the original producer’s execution paths, implicit assumptions, and custom retrieval logic. The greater mission of Knowledge Runtime is therefore not merely adding memory capabilities to a Skill, but enabling Domain Knowledge to be independently addressable by authorized consumers.

A core principle governs the design:

Runtime does not create knowledge value. It decouples valuable knowledge from the Skill that originally generated it, so the data can be consumed by other authorized Agents.

Content itself is the core asset, and the Runtime serves as the standardized access and governance layer for this asset. This framework establishes a non-negotiable boundary for multi-Agent systems:

Shared knowledge does not equal shared context.

Knowledge can be reused across Agents, but it does not need to be globally visible to all Agents, embedded into every prompt payload, or stripped of its originating domain ownership.

2. Tier One Value: Enhanced Memory Lifecycle for Individual Skills

Before discussing cross-Agent sharing, the Runtime first improves knowledge continuity for the original Skill itself. In the legacy HR workflow, the Skill relied on a fragmented combination of chat history, raw resume files, static directories, and derived graph data. None of these sources provided stable, consistent candidate identity resolution or standardized access contracts.

The HR Domain Profile establishes a deterministic data chain: display_name / aliases → candidate_id → candidate profile → source and resume version

This chain is defined within the HR domain specification. It formalizes alias resolution rules, defines what constitutes a canonical candidate archive, specifies retention policies for sensitive records, and outlines conflict resolution logic for duplicate candidate names. The Runtime executes generic, standardized operations built upon this semantic contract.

Without Runtime Contract	After Adopting Runtime Contract
Infer candidate identity from chat history, filenames, and graph records	Resolve candidate names and aliases into stable candidate_id identifiers
Conduct broad, repeated full scans of resume datasets	Return explicit status codes: found, multiple_matches, or not_found
Load ambiguous, unvalidated HR file bundles	Restrict context loading to only the selected candidate record path
Adopt inconsistent Markdown write conventions across workflows	Validate declared paths and references, perform atomic writes, return checksums, and log controlled modifications
Silent knowledge lookup failures turn into workflow crashes	Return clear status signals while retaining the original Markdown workflow as a fallback

It is critical to clarify that the Runtime does not improve the Skill’s domain judgment capabilities. It cannot evaluate candidate quality or design optimized interview questions. Instead, it strengthens the Skill’s ability to locate, load, and reference existing domain knowledge reliably. This first layer of enhancement delivers consistent task continuity and well-defined control boundaries for standalone Skills.

3. Higher-Order Value: Knowledge Survives Beyond Its Origin Skill

The architectural value of the framework fully manifests when independent Agents consume pre-existing domain content. The public HR implementation includes three Runtime-integrated workflows: resume screening, candidate detail reporting, and interview question generation.

Resume screening produces structured records of candidates, job descriptions, screening reports, and workflow logs. The other two workflows can consume this pre-built Domain Knowledge to generate their own artifacts, rather than rebuilding candidate indexing, resume caching, source registration, privacy filtering, and write logic independently. Consumer Agents do not need to understand the internal file layout of the upstream Skill.

Instead, the Domain publishes a stable knowledge contract covering:

• Record types and stable identity schemas

• Declared retrieval fields

• Restricted read paths and mandatory exclusion paths

• Source attribution and version references

• Permitted write targets

• Fallback behavior specifications

Once granted access permissions, consumer Agents can utilize this contract regardless of which Agent originally created the content. The producing model may be upgraded, or the underlying Skill may be fully replaced, yet the validated candidate knowledge remains owned by the HR Domain rather than tied to a single implementation. In this way, llm-wiki-runtime converts private Skill outputs into reusable Agent Knowledge.

It is important to note that the implementation maturity varies across the three HR workflows. All three have completed contract configuration, yet most empirical validation data comes from the resume screening pipeline. The candidate detail and interview workflows remain in early integration phases. While they belong to the same HR Domain, they cannot yet serve as fully independent validation samples for cross-domain reuse.

4. Integration Path for New Consumer Agents

“Easy integration” does not mean granting raw directory read permissions to downstream Agents. New consumer Agents connect through the same explicit boundary contract as the original producer Skill, following an eight-step standardized workflow:

1. Domain Owner Defines Knowledge Schema: The HR Profile specifies stable identity rules, record schemas, retrieval and return fields, read/write path constraints, and source attribution requirements.

2. Agent Declares Intent: The Agent states its purpose via a Service Control Policy (SCP), declaring the target domain, knowledge to access, trust level, required records, permitted artifacts, and fallback behavior.

3. Runtime Resolves Artifact and Policy: When knowledge is missing, restricted, or denied, the system returns explicit state signals instead of silent failures.

4. Agent Performs Identity Resolution: It loads candidate records and matches user input against the declared frontmatter fields, returning binary 0/1 matching results alongside read_denied flags for unauthorized access attempts.

5. Agent Loads Minimal Target Context: It injects only the necessary record subset into the context window, using file paths and checksums as precise contextual references rather than embedding full raw payloads.

6. Runtime Avoids Domain Business Judgement: The Runtime enforces access controls but does not make HR-specific decisions; the candidate detail Skill handles profile interpretation, and the interview Skill manages question design.

7. Write Operations Require Explicit Approval: If consumers need to persist new results, they follow the agreed record, artifact, and logging contract; unauthorized writes are blocked.

8. Derived Graphs Are Secondary Views: Knowledge graphs support discovery and browsing, but candidate identity resolution cannot rely solely on graph data, as graphs may become stale.

The core principle is that consumer Agents receive a standardized knowledge access protocol, not a direct copy of the producer Skill’s internal storage layout. If contextual data fits within the Domain boundary, it can be serialized as structured data rather than free-form prompts. This distinction is foundational for robust multi-Agent architectures: reusable knowledge supplies information to Agents, but it cannot silently inject executable logic or strategies.

5. Shared Knowledge Is Not Equivalent to Shared Context

Standardized knowledge reuse increases asset value, yet it also amplifies risks from misconfigured permission policies. In the HR Profile implementation, candidate retrieval only returns a minimal allowlist of validated fields, not arbitrary raw datasets. Original resume content and internal metadata are excluded from general context payloads, and cross-domain reads are denied by default unless explicitly permitted. Duplicate matching results enter a disambiguation workflow instead of automatic selection.

This design allows knowledge to be shared at the storage and protocol layers without broadcasting all private data into every prompt. However, this architecture carries tangible engineering tradeoffs:

• Stable identity schemas, record schemas, and source metadata require ongoing maintenance.

• Exact matching may fail if schema definitions or variable naming change.

• Larger numbers of consumers raise stricter requirements for source provenance, timeliness, conflict resolution, and lifecycle ownership.

• Improperly configured allowlists can expand the scope of sensitive data leakage.

• Runtime can enforce field-level allowlists but cannot independently verify whether the dataset meets ethical or compliance standards.

Content reusability depends fundamentally on data quality. Inaccurate, incomplete, or ambiguous records will propagate repeatedly once exposed as shared knowledge. This is the key reason the Domain retains ultimate ownership: Runtime makes knowledge access repeatable, but it does not normalize semantic consistency across all records or validate factual correctness automatically.

6. When to Adopt Knowledge Runtime

Knowledge Runtime delivers the highest return when all three conditions below are satisfied:

1. Data produced by a Skill retains business value far beyond the immediate task.

2. Multiple downstream Agents or workflows need consistent access to this dataset.

3. Identity resolution, provenance tracking, and write access require stricter controls than raw file system permissions.

For one-off, stateless tasks or workflows with no long-term reuse value, integrating the Runtime may create unnecessary overhead. In the HR use case, candidate archives, source lineage, version history, screening reports, and interview artifacts all span multi-task lifecycles. Without a shared runtime layer, every Agent would reparse raw sources and rebuild identity resolution independently, introducing redundant labor and inconsistent risk handling.

The Runtime centralizes generic shared mechanics while reserving domain-specific judgement logic for dedicated Skills. A small edge case illustrates this separation: some resume text includes invalid control characters. The HR extraction Skill cleans and interprets the content, while the Runtime enforces write restrictions, validates payload integrity, and guarantees the sanitized record can be trusted and reused by other Agents. This boundary segregation prevents subtle security and consistency gaps.

7. Empirical Validation and Supporting Evidence

To validate the framework described in this article, controlled tests were executed on immutable revisions of the open-source stack:

• llm-wiki-runtime @ 15cb04: 325 test cases passed

• HR Agent Copilot @ 15fb634: 10 validation test cases passed

The public validation suite verified deterministic 0/1 matching retrieval, explicit disambiguation workflows, graph-independent bounded context loading, controlled write handling, and standardized fallback logic. Within a private HR scope, 72 candidate archives were scanned. Three archives contained illegal control characters, which were fully cleaned in processing. After removing graph dependencies, precise retrieval still reliably matched target candidate records.

These real runtime observations confirm functional reliability, reduced latency, lower token consumption, improved recruitment consistency, stronger compliance controls, and measurable operational gains. However, the dataset does not prove broad adoption across diverse Agent workloads. Only the resume screening workflow has substantial real-world usage, while the other two consumer pipelines remain in early-stage integration. The evidence set supports targeted, bounded conclusions rather than universal claims for all multi-Agent deployments.

8. Conclusion

Within Agent ecosystems, the most durable asset is not a single prompt, model checkpoint, or isolated Skill implementation. It is verifiable, traceable Domain Knowledge that remains discoverable and usable for future workflows.

The llm-wiki-runtime delivers value on two levels. First, it provides more resilient, bounded memory for individual Skills. Second and more importantly, it decouples high-value domain knowledge from the implementation of its originating workflow. The Runtime itself is not knowledge; it is the governance and access layer. It does not resolve business semantics, define identity logic, or auto-correct factual inconsistencies within stored records. Its core capability is to preserve addressable, permission-bound knowledge assets even as Skill implementations evolve or get retired.

The central takeaway of this architecture is straightforward: Skills can be replaced, but the knowledge they accumulate should not disappear.

Learn more: https://4sapi.com