02 / CAPABILITIES
Capabilities,
organized by task.
The model is only the start. Retrieval, orchestration, tools and routing together decide whether AI can participate in business reliably. Combined per project; not a full stack by default.
Retrieval-Augmented Generation (RAG)
Retrieve first, then answer. Documents are chunked, embedded and indexed; at query time relevant passages are retrieved and sent to the model with the question, and answers cite sources. Answer quality depends on document quality and retrieval tuning — model memory never replaces source material.
- Document parsing and chunking (PDF / Word / web / tables)
- Embedding and index construction
- Hybrid retrieval and relevance tuning
- Source citation and "no basis, no answer" constraint
Applicability: documents available for structuring. Complex layouts are tested with real files before scope is agreed.
Agent & Workflow Orchestration
Break multi-step tasks into nodes: analyze, retrieve, generate, check, publish. Each node has defined input and output; key nodes keep human review; failures retry; the process is traceable. Running in production for content pipelines.
- Task breakdown and node definition (input, output, conditions)
- Human review nodes and exception handling
- Inter-node data passing and versioning
- Run records and issue localization
Applicability: the task flow can be clearly described. If the process itself is unclear, do process analysis first, then orchestration.
MCP Toolchain
Connect external capability through a standard protocol: search, file read/write, content publishing, business system APIs. A tool is integrated once and reused by many tasks; permissions are controlled separately — the model never calls arbitrarily.
- Standard tool integration (search / files / publishing)
- Business API encapsulation
- Tool permission and call-scope control
- API documentation and call records
Applicability: external systems provide APIs or login-capable web capability. For systems without open APIs, integration approach is assessed first.
Multi-model Routing
Unified scheduling of local and cloud models: assign models by task difficulty, set fallback by cost, switch automatically when the primary model is unavailable. Models are replaceable — the system is never locked to a single vendor.
- Model access (local / cloud / API)
- Task-based assignment and priority strategy
- Failure fallback and backup model switching
- Call monitoring, usage and cost records
Applicability: multiple models in use or availability requirements. A single sufficient model needs no routing layer.
PRINCIPLES
Selection principles,
before the stack.
No trend-chasing, no stack padding. Every component answers three questions: what breaks without it, what does replacing it cost, and which concrete problem does it solve?
QUESTIONS BEFORE WE BUILD
Let's be clear first.
Must all capabilities be built together?
No. Select by task: knowledge Q&A may need only RAG; a content pipeline needs orchestration plus tools. Verify with the minimal combination first, then extend by results.
Which model vendor? Will we be locked in?
The proposal lists models and selection rationale; local and cloud can be accessed together. Models are replaceable and interfaces are standard-encapsulated — no single-vendor lock-in.
In-house R&D or open source?
Mature open-source components primarily; in-house work concentrates on business process and adaptation layers. Component versions and licenses are stated in the proposal; components of unknown origin are not used by default.
How are post-launch issues handled?
Hand over configuration docs, run records and test cases; provide issue localization and update support as agreed. Where model quality degrades, re-verification and tuning are scheduled.