Third-party App development handbook

This handbook explains how to build Apps with the public interfaces of Agent Core, covering APIs, integration examples, Skills, and App knowledge maintenance. The Chinese edition starts at 中文; each page has a corresponding *.en.md file in the same directory.

API handbook · Public symbol reference

Agent Core integrates with applications through public interfaces and works with different service frameworks, databases, model providers, and front ends.

The API reference is also part of this development documentation: API home, Core, Support, Kit. This handbook explains how to combine these interfaces and take on application responsibilities; signatures, parameters, returns, and exceptions are governed by the corresponding API pages.

Start from the task to be completed

First read How the mechanism works to understand overall collaboration, the difference between tasks and nodes, workflow progression, the timing of model and tool calls, and the App knowledge answering example.

Start by providing a ChatProvider, then call new ModelRunner({ provider }).invoke('你好'). Core itself provides the plain text path and default run settings; Support and Kit are optional. Tools, context processing, persistence, and complex orchestration are integrated step by step as needed.

Task	Recommended entry
Create a runnable Agent App from an empty directory	Create an App
Install into an existing project, configure the model connection	Installation and integration
Generate one reply	Model calls
Declare tools, authorization, execution in one place and return results	Tool integration
Understand the difference between raw model streams and complete delivery	Stream boundaries
Orchestrate conditional loops and multi-stage tasks	Registration and orchestration
Control context length and compression	Context policy
Generate and check answers from existing knowledge	Knowledge documents, Knowledge answering contract
Handle user materials and persistence	Material boundaries, Memory and continuous accumulation
Integrate logs, cancellation, and failure handling	Delivery and operations
Verify a complete integration	Integration checks

For partial integration approaches see Examples; for App data field design see Record examples. For manual preparation and iteration see the Maintenance handbook; for the shared workflow and Skill used by coding Agents see Agent-assisted development. These assets are not automatically scanned, installed, published, or written to a database by the library.

How the three kinds of interfaces collaborate

Core owns the execution service and the calling/callback contracts, such as workflow state commits, model call budget, tool input → execution → output, and real call receipts. Support helps the App construct these calls and the implementations that get scheduled. Kit is chosen by the App on its own and owns its own local business models and specifications.

Support is the unified namespace for integration support and contains multiple modules. A single optional capability module is called a Kit; multiple Kits are aggregated by /kits. A Kit may have its own helper functions and shared utilities internally.

App authentication, storage, knowledge loading, and run configuration
    → Support assembles model and context
    → Core executes registered workflows, model calls, and tools
    → App handler calls Knowledge / Answering / Presentation Kits as needed
    → App checks and delivers the result

Names, parameters, and conclusions proposed by the model are not authentication, persistence authorization, or execution receipts. An App may skip a given Kit but still has to comply with the Core interfaces it actually uses. After adopting a Kit, comply with that Kit's local input and output constraints.

What a new App must provide

• Basic run: the Provider's model connection and the actual input. Core provides the default budget, single-call timeout, signals, and plain text transport; override as needed.
• When enabling tools: the business implementation plus the required identity, access control, parameter, and result constraints.
• When enabling persistence: sources, user ownership, storage and retention policy, and failure recovery.
• When enabling complex orchestration: associations among declared nodes, tools, model tools, knowledge, checks, and output.

No default need to enable long-term memory, user profiles, experience libraries, vector databases, or dynamic tool loading. Deliver a read-only, single-round App with explicit sources first, then integrate each item according to real requirements.

Provided versus still-App-owned tools

Provided by the library	Still to be implemented by the App
Knowledge document parsing, in-memory catalogs, section selection, and snapshots	Reading files/databases, knowledge authorization, version computation, persistent import/modification/deletion
Answering task lists, checks, and bounded local repair	Task business definition, fact reading, model calls, business validation, and allowed fallback
Support context assembly and model call format adaptation	Request data, server-side identity, source trustworthiness, storage, and model connection configuration
TextSkills text catalog loading and metadata validation	Actual file reading, tool reference verification, update publishing, and reload timing
Core run records and optional diagnostics, Support's optional Provider observer	Log output, storage, sensitive content policy, queries, and operations

For copy-and-run offline complete code see Service answering example. parse/define parse and compile knowledge in memory. For knowledge preparation and updates see Knowledge maintenance flow.

Profile merging, experience learning, long-term memory storage, document persistence, vector index storage, and file ingestion are implemented by the App. The relevant chapters provide integration boundaries and templates.