AI Employee

A named role: which skills it claims, and what its work needs installed. It is configuration — it does not execute anything by itself.

This is the part people most often read backwards, so it is worth stating first: an AI Employee does not run your task. The Runtime runs it, on your machine, under the permission tier you granted. The employee is the description of a role — a name, a set of claimed skills, and the environment those skills need.

Keeping those separate is deliberate. If the employee were the thing that executed, then hiring one would be a way to widen what can be done without granting permission, and the permission contract would have a hole in the shape of a job title.

Skills

The global skill catalogue — every skill the system knows about. It is not the same question as “what can this employee do”, which is the employee's own card.

A skill an employee claims but cannot currently perform is shown as a gap rather than hidden. A card that advertises a skill the environment cannot support is worse than an empty card: it produces a task that fails late instead of a role you can see is not ready.

Environment

Each role needs some toolchain present — a language, a build tool, an SDK. The console reports readiness from a real probe, not from a list of assumptions.

Looks at what is actually installed on this machine.

Installs what registered employees are missing. It works from what the registered roles actually need, not from a fixed list of everything KernelHub has ever supported.

“Unknown” is not “all installed.” Before the probe has run, readiness is unknown, and the console says unknown. That distinction matters more than it looks: a blank readiness panel that quietly reads as “fine” is how a task gets sent to a machine that cannot build the project.

What works in v1.0.2

Being precise about this, because the surfaces differ:

• Listing and inspection work. icloser employee list and icloser employee show report the registered roles; the console shows them with their environment readiness.
• Environment probe and provisioning work — icloser env probe and icloser env bootstrap, and the console's provisioning action.
• Hiring is in the iPhone app and in the local console. An employee belongs to your account, not to a workspace, and is then assigned to the workspaces it works in. icloser employee create is on the CLI too, but we have not verified that path end to end, so this page does not document it as the way to hire.

We would rather tell you which half works than let you find the other half at the moment you needed it.