Capability Without Chaos: Skills, Tools, Knowledge, and Memory

LobeHub’s value depends on what an Agent can bring into an operation—and what it is allowed to do once that material is present. This chapter examines the boundary between Skills, callable Tools, external integrations, retrieved knowledge, and personal Memory. The practical goal is to decide what should be discovered, what should be loaded, what should be authorized, and what should persist, rather than treating every extension as another paragraph in a giant prompt.

That distinction follows directly from the runtime loop. A model cannot act on an integration it has never been told exists, but exposing every installed capability on every request consumes context and increases the chance of a confused or inappropriate call. LobeHub addresses the problem with several layers of selection: workspace installation, per-Agent enablement, operation snapshots, step-level activation, prompt injection, and execution policy. The layers overlap, but they are not synonyms.

From installed capability to authorized action

A Skill is best understood as reusable expertise or operating guidance. It can describe a method, a domain convention, a template, or instructions for using a related set of capabilities. A Tool is an executable function with a name, input schema, handler, and result. A Skill may explain when to use a Tool, but it does not itself perform the action. This is the practical meaning behind LobeHub’s older shorthand that Skills are what an Agent knows and Tools are what an Agent can do.

The current Skill Management guide makes the ecosystem broader than a single plugin directory. LobeHub includes built-in tools, LobeHub-native OAuth integrations, Composio-connected services, community MCP servers, and custom MCP servers. MCP is a connection protocol and tool surface, not a guarantee that all connected services have the same authentication, latency, data policy, or reliability. A marketplace entry can be installed in the workspace and still require configuration or authorization before an Agent can use it.

The first control point is the workspace. Installation makes a capability available to the environment; enabling it for an Agent determines which persistent operating identities may use it. LobeHub’s tool engine then merges configured tools with defaults, checks whether the selected model supports function calling, filters manifests through an enable check, and converts the surviving API descriptions into normalized function schemas. If function calling is unavailable, the tool set is not simply sent anyway. That prevents a configuration that the model cannot understand from masquerading as an active capability.

The second control point is the operation. LobeHub resolves an operation-level tool set and Skill set when a run is prepared, then applies step-level activations accumulated during the run. A tool may be discoverable without being in the active call set. A Skill may be listed as available while its full instructions remain unloaded. When a Skill has real content, the context engine can inject that content; otherwise it remains discoverable so the Agent can activate it rather than becoming an invisible, nominally enabled feature.

This creates a useful sequence:

  1. The workspace installs or connects a capability.
  2. An Agent is enabled to use it.
  3. The current operation receives a snapshot of the relevant capability surface.
  4. The model sees lightweight discovery information or selected full instructions.
  5. A step activates or selects what it needs.
  6. The runtime applies allow-lists and intervention policy before execution.

Each step answers a different question. “Is this capability available?” is not the same as “was it loaded into context?” and neither is the same as “may this call execute now?” Conflating those questions is how a convenient integration becomes an invisible authority expansion.

The three scopes become clearer in a coding example. A workspace may have a GitHub connector installed. A code-review Agent may be enabled to use it, while a writing Agent is not. A particular operation may then be limited to reading issues and pull requests, even though the connector exposes other APIs. Finally, a single model step may receive only the function needed to inspect one repository. At each boundary, the system can narrow authority without uninstalling a useful capability for everyone else.

The reverse is also important: a capability can be present but unusable. The selected model may not support function calling; an OAuth connection may be pending; the Agent may not have the Skill enabled; an operation may restrict the API; or an intervention policy may stop the call. LobeHub’s layered design makes these different failure causes distinguishable. A missing tool schema is a context or resolution problem, while a rejected call may be an authorization decision, and an execution error belongs to the tool or its external service. That diagnostic separation is more valuable than simply showing the model that an action failed.

Dynamic activation also has a temporal meaning. An operation-level snapshot gives a run a stable starting point, while accumulated step activations let later calls build on what earlier calls discovered. This supports a research workflow that begins with a lightweight search capability and loads deeper instructions only after the request reveals what kind of evidence is needed. The operation can grow its working set, but the growth remains attributable to a step and does not silently rewrite the Agent’s permanent configuration.

LobeHub’s dynamic tooling reflects the same design. The tool resolver starts from the operation’s immutable set, adds accumulated or current activations, keeps manifest information for name resolution, and can filter individual APIs to an allowed set. A wildcard deactivation can remove all callable tools for a forced final response. User-selected tools and Skills can be appended to the current request as ephemeral context and deduplicated against earlier selections. These mechanisms let a user say, in effect, “use this for this request,” without permanently changing the Agent.

Agent Builder is the durable counterpart. Through natural conversation it can update an Agent’s model, role, prompt, metadata, and enabled capabilities; search available integrations; and install or connect tools. The management runtime preserves the difference between configuration and connection state. Enabling a built-in tool is different from completing OAuth for an external service, and installing a marketplace MCP is different from merely searching for one. The convenience is real, but a conversational mutation still deserves a visible review because it changes future operations, not just the current prompt.

Consider a research Agent asked to prepare a current market briefing. The Agent may have a web-search Skill available but not its full instructions loaded. The model can discover it, activate the relevant guidance, and call a search Tool. A project knowledge base may be available at the same time, but the search result and the internal document are separate evidence sources. If the next step would publish the briefing to an external channel, that action should pass through a new authority check. The fact that the Agent was allowed to gather information does not imply that it is allowed to distribute the result.

classDiagram class Agent { persistent role and model enabled capabilities } class Skill { reusable instructions activation state } class Tool { callable function input schema } class Integration { connection state external service } class Knowledge { retrieved evidence document scope } class Memory { durable personal context } class ContextPipeline { ordered prompt assembly } class Operation { scoped authority transient selections } Agent --> Skill : enables Agent --> Tool : exposes Tool --> Integration : may call Agent --> Knowledge : attaches Agent --> Memory : may recall Operation --> ContextPipeline : builds Skill --> ContextPipeline : injects guidance Knowledge --> ContextPipeline : supplies evidence Memory --> ContextPipeline : supplies context ContextPipeline --> Operation : produces payload Operation --> Tool : authorizes call

Knowledge and personal context are not the same thing

The capability graph explains what can enter an operation; the context pipeline determines how it enters. LobeHub’s context engine processes messages in an ordered sequence. It can filter placeholder residue and truncate history before assembling system instructions. It then adds Agent identity, project and workspace instructions, model information, Skills, tool definitions, and history summaries; injects Memory, Group context, plans, knowledge, documents, and tool discovery; augments the relevant user message with page, task, selected-tool, or topic-reference context; transforms grouped messages; handles multimodal content and tool calls; and performs final cleanup.

The ordering is not cosmetic. Stable instructions belong in a different place from high-churn runtime guidance. A document selected for one request should not be mistaken for a permanent Agent rule. A tool result nested in a grouped message may need to be flattened before the tool-call processor can correlate it. A Skill whose complete content is already in the system prompt should not be copied again into a tool result and charged twice against the model’s context. LobeHub’s design treats these as data-shape and ownership problems, not only prompt-writing problems.

Knowledge retrieval has its own boundary. The Resource Library describes documents being split into chunks, converted into vector embeddings, stored with metadata, and searched for semantically similar material. A query is then matched against those chunks and the most relevant excerpts are passed to the Agent. This can find “authentication” when a user asks about “how to log in,” but it does not guarantee that the returned chunk contains the decisive qualification or the latest version of a document.

That is why the documentation recommends a two-step pattern: search first, inspect the relevant results, then read the selected files in full when the question requires it. It also advises resolving pronouns and vague references into concrete entities. “What does it do?” supplies little semantic signal to a vector search; “What does the payment authentication workflow do?” gives retrieval a subject and a scope. The difference is not stylistic. It changes which evidence reaches the model and therefore changes the basis of its answer or action.

Knowledge Bases are durable evidence stores, but they are not personal Memory. A product specification, policy manual, or research corpus should remain attributable to documents and libraries. Memory is intended for reusable personal context such as a communication preference, an enduring role, or a recurring pattern. Conversation history records what happened in a Topic. A Page or Notebook document preserves authored material. If all of these are poured into one context bucket, the Agent loses the ability to tell an instruction from evidence, a current request from an old decision, or a user preference from a one-time constraint.

Transient selections provide another useful test. A user can select a Skill or Tool for one request, attach a page, reference another Topic, or provide task-specific context. Those inputs should affect the current operation without silently rewriting the persistent Agent. Conversely, if every conversation needs the same behavior, changing the Agent’s role or a durable preference is more coherent than manually selecting the same instruction each time. The correct layer is determined by expected lifetime and scope.

Memory sits at the edge of this chapter because it combines capability with continuity. LobeHub’s Memory implementation uses structured layers and injects retrieved entries into context when enabled, but its purpose is not to expose an arbitrary archive. It tries to make personal information reusable and scoped. The distinction still requires care: a remembered preference can change how the Agent responds, while retrieved project knowledge should support what the Agent says about the world. The next problem is not how to add more memory, but how to decide what deserves persistence and how to correct it when it becomes wrong.

Every additional input also imposes costs. More tool definitions consume context before the model has done any work. More retrieved chunks increase tokens and latency, and irrelevant passages can compete with the user’s actual request. More Skills can create overlapping instructions. More historical messages can preserve useful rationale while also preserving obsolete assumptions. A context pipeline can make these sources explicit, but it cannot decide relevance perfectly on its own; selection remains part of Agent design and user judgment.

The practical rule is therefore conservative. Install broadly only when the workspace can govern the capability. Enable narrowly for each Agent. Load full instructions when they are useful for the current step. Retrieve evidence with concrete, reviewable queries. Keep personal Memory, project knowledge, conversation history, and one-off selections in their proper scopes. Finally, treat authorization as a separate boundary after context assembly: the model may know that an action exists without having permission to perform it.

LobeHub’s capability system is strongest when these distinctions remain visible. It can make a specialized Agent feel ready without sending every integration into every prompt, and it can let an operation grow its tools without changing the Agent’s permanent identity. The remaining test is whether a reader can use the distinctions in a complete run: identify the stable Agent state, follow the selected context, see the authorized action, and account for the result. That integrated view is what turns a set of capabilities into a working Agent operation.

References