ai pkm icore mypka agentic-workflows llm-orchestration knowledge-management tool-agnostic mcp-servers automation

Architecting Tool-Agnostic Knowledge Systems: Decoupling Core Data from LLM Orchestration via the MyPKA Framework

5 min read

Architecting Tool-Agnostic Knowledge Systems: Decoupling Core Data from LLM Orchelarion via the MyPKA Framework

In an era of rapid AI advancement, a critical vulnerability exists in modern productivity workflows: tool dependency. As Large Language Models (LLMs) and specialized agents evolve at an exponential rate, any personal knowledge management (PKM) system that is tightly coupled to a specific software's proprietary API or interface risks obsolescence. To build a resilient intellectual infrastructure, one must adopt a methodology where the underlying knowledge outlives the ephemeral tools used to process it.

This article explores the technical architecture of the iCore for Life methodology and the MyPKA (Personal Knowledge Assistant) framework—a system designed to decouple "Core Applications" from "Utility Apps" through an agentic orchestration layer.

The MyPKA Agentic Architecture: Orchestration via Delegation

The MyPKA framework operates on a multi-agent system (MAS) architecture, centered around a primary orchestrator agent known as Larry. Unlike simple single-prompt LLM interactions, the MyPKA setup utilizes a delegated task model where Larry acts as the routing layer.

When a user provides an input, Larry parses the intent and dispatches the workload to specialized sub-agents, each governed by specific "written contracts" (system prompts) that define their operational boundaries. This modularity ensures that updates to one agent's logic do not destabilize the entire pipeline. The current team includes:

  • Larry (The Orchestrator): Handles initial request ingestion and task delegation based on agent-specific capabilities.
  • Silas (The Parser): Operates strictly within plain-text environments, ensuring high interoperability across any text editor.
  • Iris (The Markdown Architect): Specializes in structured Markdown generation, focusing on syntax precision and hierarchical formatting.
  • Charter (The Synthesizer): Performs high-level abstraction, transforming unstructured "messy" data into coherent, single-page summaries.
  • Pixel (The Visual Generator): Manages image synthesis and generative assets.
  • Vera (The Validator/QA): Acts as a human-in-the-loop or automated verification layer to audit outputs before final deployment.
  • Mac (The Integrator): Manages the interface between the local folder structure and external tool ecosystems.
  • VEX (The Gatekeeper): Enforces strict protocol adherence for any new tools or integrations introduced to the ecosystem.

Decoupling Strategy: Core Applications vs. Utility Apps

A fundamental principle of the iCore framework is the distinction between Core Applications and Utility Apps. This distinction is vital for maintaining system integrity during tool migrations.

1. Core Applications (The Persistence Layer)

Core applications are the repositories of critical, long-term information. These include tools like Heptabase, Notion, Tana, or Obsidian. In these environments, data is structured into nodes, databases, or markdown files. The "truth" resides here. If a core application is removed, the system loses its foundational knowledge.

2. Utility Apps (The Processing Layer)

Utility apps are ephemeral tools used to manipulate, move, or augment the data within the Core Applications. Examples include Raycast, cloud-based LLMs (ChatGPT, Claude), and MCP (Model Context Protocol) servers. These are "stateless" in the context of the long-sought knowledge; they provide the computational power or the interface but do not hold the permanent record.

By treating AI agents as Utility Apps, we ensure that if a superior model or tool emerges, the user can swap the processing layer without re-architecting their entire knowledge base.

Technical Evolution: From API Limitations to Local Context Injection

A significant technical pivot in the development of MyPKA was moving away from direct API-based manipulation of third-party tools (such as Heptabase) toward a Local Folder Approach.

Previously, attempting to use an LLM to manipulate nodes within a tool like Heptabase via its API presented significant limitations. Specifically, the AI struggled with complex graph operations—such as creating new nodes and establishing bidirectional links between existing nodes—due to the constraints of the available API endpoints. The lack of granular control over the graph's topology made automated orchestration unreliable.

The solution was to implement a local-first architecture using Markdown files within a structured directory (the "scaffold"). By pointing LLMs and MCP servers toward a local folder, we achieve several technical advantages:

  1. Enhanced Context Injection: We can feed much larger volumes of context into the model by leveraging the file system as a RAG (Retrieval-Augmented Generation) source.
  2. Granular Control: The agentic team can manipulate files using standard I/O operations, which are more robust than complex API calls.
  3. Tool Agnosticism: Since the data exists as plain text and Markdown, any tool—be it an Obsidian plugin or a custom-built Python application—can read, write, and link these files.

The iCore for Life Implementation Layer

The "iCore for Life" scaffold serves as the implementation layer of this methodology. It provides a standardized directory structure (Inbox, Planner, MyLife) that can be mapped onto any tool stack. Whether using Tana for rapid capture or Notion for project management, the underlying folder-based logic remains constant.

As we move toward more advanced implementations, including custom interfaces and expanded agent "expansion packs," the goal remains: to create a system where the user's intellectual capital is protected from the volatility of the AI software lifecycle.