Chapter 5 — BlockFlow · AI nodes · Agent node
5.2.6.1 Supervision & Learning — Overview & Lifecycle
Agent node configuration for teacher–student supervision, safe handover, trace collection and progressive student autonomy — extending the Agent node with a supervised learning configuration while preserving current single-model behaviour when the feature is disabled.
Overview
Supervision & Learning introduces two model roles inside a generic Agent node: a teacher and a student . The teacher provides the stronger reference behaviour, while the student gradually progresses from observation to fully autonomous execution.
The feature is intentionally domain-independent: tool names, business rules, routes and workflow-specific validation remain external, supplied at runtime through MCP tool definitions , schemas, policies, prompts and the existing BlockFlow configuration.
Objective
Collect useful production learning data and improve the student model, without allowing an unproven student decision to reach the user or execute a tool before the configured safety checks have selected it.
Core design principles
- Backward compatible — if
data.learningis absent or disabled, the current model configuration remains authoritative. - Profile based — model endpoints, credentials, capabilities, prompts and policies are selected through reusable profiles instead of raw per-node infrastructure values.
- Safe by construction — critical handover and execution invariants are visible but cannot be weakened by ordinary workflow configuration.
- Immutable selection — rejected student output is trace data only; it is never added to canonical conversation history and cannot execute an MCP tool.
- Learning off the critical path — synthesis, dataset curation, evaluation and fine-tuning run asynchronously after live interaction processing.
- Generic tool safety — the Agent validates decisions against the exact tool definitions and schemas offered for that model round rather than hardcoding use-case logic.
Lifecycle modes
The lifecycle mode defines which model is authoritative and when synchronous teacher review is required. The same Agent can move through these phases as the student demonstrates sufficient quality and safety.
| Mode | Primary behaviour | Practical meaning |
|---|---|---|
| Phase 1 — Teacher primary | TEACHER_PRIMARY | The teacher serves the user. The student may run in shadow, but its decision is recorded only for comparison and learning. |
| Phase 2 — Student fully gated | STUDENT_GATED | The student proposes every decision; the teacher must accept, replace, block or escalate it before delivery or tool execution. |
| Phase 3 — Student supervised | STUDENT_SUPERVISED | The student is primary. Teacher review is triggered for protected or unusual decisions, failures and configured samples. |
| Phase 4 — Student autonomous | STUDENT_AUTONOMOUS | The student serves directly after deterministic validation. Teacher review is primarily background auditing and quality measurement. |
Important
“Disabled” is controlled by the main enable toggle and is not a fifth lifecycle phase. Runtime may temporarily move to a safer effective mode, such as teacher-only degradation, without rewriting the design-time JSON.
Node versus platform configuration
The Agent node stores references and resolved, versioned snapshots needed to make a workflow revision reproducible. Reusable registries own infrastructure and organisation-wide policy.
| Agent node | Reusable platform configuration |
|---|---|
| Enable/disable state and lifecycle mode | Model endpoints, provider and deployment configuration, and credentials |
| Teacher and student profile references and resolved versions | Supervisor prompt profiles |
| Approved per-node generation and timeout overrides | Supervision, trace, privacy, synthesis and deployment policies |
| Review sampling within policy limits | Evaluation releases |
| Trace and synthesis enablement and policy references | MCP tool effect, confirmation, idempotency and sensitive-field metadata |