What it is
Kora HAI is the newest and least settled of the platform pillars. The architecture below is specified and the core components are landing; treat interfaces as subject to change and expect to work with us directly rather than against a frozen API.
Most agent frameworks fail closed: no tool for the job means no answer. Kora HAI treats a missing capability as a task rather than a dead end. A gap raises an event, a set of specialised sub-agents turn that event into a candidate skill, a sandbox proves it, and a deployment manager puts it into service — or rolls it back if reality disagrees.
The pattern is deliberately composable. The same Creator / Checker / Validator loop can drive a coding agent, a research agent or a personal assistant; what changes is the domain, not the machinery.
The healing loop
Detect
An agent hits a capability it doesn't have, or a skill fails in execution. That raises a skill.missing or skill.execution.failed event on the platform event bus — a signal, not an exception.
Assess
An Assessor searches what already exists — the skill registry and the shared brain — before anything is written. Most gaps are not new; they are something already built, described differently.
Generate
If something genuinely new is needed, a Creator drafts it, a Checker reviews it for security, correctness and standards, and a Validator decides: approve for testing, or return it to the Creator with the Checker's notes. That is a conversation between agents, not a single generation.
Test
The draft runs in an isolated sandbox against mock inputs — including assertions on non-text outputs and, when extending an existing skill, that skill's original tests. Failure routes feedback back into the loop, bounded by a retry limit.
Deploy
Blue/green. The proven version goes live only after shadow traffic agrees with it, and the previous version stays warm and ready to take back over.
Remember
The gap, the reasoning, the decision and the outcome are persisted into the concept graph and memory — so the next occurrence starts from experience rather than from scratch.
Assessment: build is the last resort
The Assessor's job is to avoid generating code. It emits one of a small set of decisions, in rough order of preference:
| Decision | Meaning |
|---|---|
REUSE_SKILL | Something already does this — found by semantic search over the skill catalogue, not by exact name. |
COMPOSE_CHAIN | Existing primitives can be assembled into the capability. No new code is written. |
EXTEND_SKILL | An existing skill nearly does it and can be widened — its original tests must still pass. |
CREATE_SKILL | Genuinely new. Enter the full generate-and-verify loop. |
CREATE_BACKEND | The capability needs somewhere to keep state or receive callbacks. |
SPAWN_DOMAIN_AGENT | A recurring pattern is substantial enough to deserve its own specialist. |
The composition path matters more than it looks: a system that can assemble what it already owns grows capability without growing attack surface. Resolution is also fail-soft — if a reuse target can't be resolved, the loop degrades to creating the skill rather than erroring out.
Agent tiers
Agents are structured, not a flat swarm.
| Tier | Role |
|---|---|
| Kernel | The minimal always-present core, with a seed set of primitive skills — execute code, publish events, and the handful of things needed to bootstrap everything else. |
| Domain agents | Specialists that watch for gaps in their own area. The system boots with two: a general domain for everyday work, and a meta domain for self-improvement and monitoring the system itself. |
| Worker agents | The Assessor, Creator, Checker, Validator and chain composer — spawned per healing episode, not resident. |
Domain agents have a lifecycle. One that goes unused is hibernated and its skills fold back into the general domain — so a system that spawns specialists opportunistically doesn't accumulate dormant ones forever.
Seed skills
The kernel boots with a deliberately small set of primitives. Everything else is built from them:
code_execute | Run generated code in the sandbox. |
llm_call | Reach a model through the reasoning engine. |
web_search | Research an unfamiliar capability before drafting it. |
skill_registry_query | Find out whether the capability already exists. |
graph_query | Ask the concept graph what is already known. |
featurebus_publish | Emit an event — including the one that starts a healing loop. |
file_read_write | Read and write working files. |
A small seed set is the point: the smaller the trusted base, the less there is to get wrong when the system starts extending itself.
Not everything deploys itself
Generated capabilities are tiered by what they touch:
| Tier | Path to production |
|---|---|
| Evergreen | Routine capability. Passes the sandbox and shadow testing, then deploys automatically. |
| Sensitive | Touches something that warrants judgement. Stops at a human approval gate no matter how clean the tests were. |
Where that line sits is yours to configure. Autonomy you can't scope isn't a feature.
An agent reviewing its own output is a weak check — the same context that produced a flaw tends to excuse it. Splitting drafting from review, and giving a third agent the decision, is what makes the verification meaningful rather than ceremonial.
Validation sandbox
Nothing generated reaches production without executing somewhere it can do no harm first. Skills run in an isolated container against mock context, and the sandbox checks more than "did it return".
| Assertion | What it catches |
|---|---|
| Functional | Does it do the thing, on the mock inputs. |
| Multi-modal | Non-text outputs verified by a second model — an image is checked by looking at it, not by trusting a filename. |
| Security & standards | The Checker's concerns, enforced rather than advisory. |
| Backward compatibility | When extending a skill, its original test suite runs — a widened capability must not quietly break the narrow one. |
Failures return to the generate loop with the reason attached, bounded by a retry limit so a hard problem ends in escalation rather than an infinite spend.
Blue/green & limits
A system that modifies itself needs a way to be wrong safely. Kora HAI treats every change — to a skill, an agent, or the kernel — as a firmware update.
| Stage | Behaviour |
|---|---|
| Blue stays up | The current version keeps serving all live traffic. It is never paused while an upgrade is built. |
| Green is built aside | The new version is drafted, checked and sandboxed in an isolated namespace. |
| Repair, don't crash | A green failure returns to the Creator and Checker. Blue is unaffected — a failed self-upgrade is invisible to users. |
| Shadow first | Green takes a share of read-only traffic and its results are compared against blue before it earns promotion. |
| Cutover with a net | Green goes active only on a better outcome. Blue is held suspended, and a live failure in that window rolls straight back. |
Repeated healing failures trip a breaker and escalate to a human instead of looping. Self-healing without a budget ceiling is just an expensive way to fail — the limit is what makes autonomy safe to switch on.
What it remembers
The healing loop is a first-class citizen of the platform's memory, not a log file.
Every event is retained and projected into the Cognition OS graph, so the agent's history is queryable as structure — which gap led to which skill, which decision produced which outcome. Skills, chains and primitives are graph nodes with real types; episodes and reasoning land in Kemory.
The relationships between them are weighted and evolving: edges between skills, tasks, agents and events strengthen with successful execution and frequent use, so the paths the system reasons along optimise from its own experience rather than from a static design.
This is the part that compounds. A framework that generates skills gets more capable; one that also remembers why gets better at deciding whether to generate at all.
What you can build
| Use case | What Kora HAI gives you |
|---|---|
| Agents that don't dead-end | A capability gap becomes a queued piece of work with an audit trail, instead of an apology to the user. |
| A growing skill library | Capabilities accrue as reusable, tested, versioned skills — discoverable by meaning, so they get reused rather than rebuilt. |
| Domain specialists | Recurring patterns earn their own agent, with hibernation so the roster doesn't sprawl. |
| Self-improving operations | A meta domain that watches the system itself and proposes its own upgrades, behind the same review and rollback. |
| Explainable autonomy | Every generated capability traces back through the reasoning and the decision that produced it. |
Availability & access
Kora HAI is in alpha. The architecture is specified and core components are landing; it runs on the rest of the platform — reasoning for generation, the graph and memory for persistence, the event bus for detection. It ships as part of the SeKondBrain platform, licensed, not open source.
Where it runs
| Model | What it means |
|---|---|
| Multi-tenant cloud | The default. We operate it; your organisation gets its own isolated tenant, skill registry and endpoint. |
| Your own cloud | For enterprise. Deployed into your cloud account — which for a system that generates and runs code is usually the answer. |
What you get when you're set up
| A unique URL | Your organisation's own endpoint, alongside the reasoning, graph and memory services it builds on. |
| Credentials | Scoped to your organisation; generated skills are registered in your registry, not a shared one. |
| Domain configuration | Which domains you start with, the retry and circuit-breaker budgets, and where the human approval gate sits. |
| Direct support | In alpha you work with our team rather than against a frozen SDK — interfaces will move, and we move them with you. |
We're working directly with early partners on this one. If autonomous capability generation is interesting to you, the useful conversation is about your domain and your risk tolerance.
Email hello@sekondbrain.ai with the subject “Access for Kora HAI” and tell us what your agents keep failing to do.