Own the model–tool loop
The runtime uses AI SDK streaming with explicit step and retry limits, tool-loop detection and per-step usage accounting. Model output and tool execution have separate responsibilities.
Coding Agent.
The historical coding application behind Knolume Runtime
An archived TypeScript coding-agent application with CLI, Feishu and scheduled-task entry points. Its reusable core continues as the separately maintained Knolume Runtime library.
- Area
- Agent systems
- Implementation focus
- Model–tool loop, tool registry, permissions, context compression, memory and guardrails.
- What you can inspect
- Trace the historical application and the extraction into the current runtime library.
The problem
A coding agent needs to do more than produce a plausible response. Tool calls change files and run commands, long sessions accumulate context, and cancellation must reach work already in progress. Those behaviors need explicit execution contracts.
How the pieces fit
Agent execution
Input checks & context
Model–tool loop
Validate → Authorize → Execute
Output checks & trace
Shared tool boundary · Run-scoped cancellation
A conceptual map of the inspected implementation: a model–tool loop coordinates execution; the tool pipeline owns validation, permissions and execution; context, traces and guardrails support the run.
Key engineering decisions
Give every tool the same execution boundary
A shared pipeline applies hooks, validates final arguments, checks permissions, coordinates locks and records the outcome. Built-in and connected tools use the same policy boundary.
Separate generation from permission to act
Parallel input checking can overlap with model generation, while output events are buffered and tool execution waits for an input-effect gate. A rejected check cancels the run and discards buffered output.
Treat context as a managed resource
Context compression, project rules, memory tools and local traces are separate modules. The runtime exposes what it carries into a run and records usage for later inspection.
Reliability & failure handling
Cancellation travels with the run
Run contexts carry an AbortSignal through model execution and tool calls. The guardrail path bounds how long it waits for cancellation to converge.
Permission outcomes remain distinct
Completed, aborted, blocked, invalid, denied and failed tool calls are different audit outcomes. A denied operation cannot be presented as completed work.
Trace without exposing secrets
Audit handling recognizes sensitive fields and supports guardrail redaction. Trace inspection and dedicated guardrail tests are part of the implementation.
Evidence & scope
Source links are pinned to the reviewed revision so you can follow each implementation detail.
Application wiring
Historical assembly of models, tools and application entry points.
src/main.tsMigration relationship
What moved to Knolume Runtime and what remains application-specific.
README.mdWhat this case establishes
Continue to Knolume RuntimeArchived historical application, not the current runtime integration path. Knolume Runtime carries forward reusable capabilities; APIs, configuration and stored data are not assumed compatible.