Introduction to Agentic Ops
Agentic Ops is work on a domain carried out by agents: not “the agent helps a developer write code” but “the agent runs development inside an environment from assignments, while the human keeps the framing of tasks, the acceptance and the authorization of the result”. The two later steps of the Academy are about this.
What changes when the subject is knowledge
In an ordinary project the subject of development is program code. In a regulated medical ecosystem the subject is different: knowledge that trusted program code executes — thresholds, rules, correspondences between terms. Code here is a strict executor, not a carrier of meaning, and the cost of a mistake lies not in a poor build but in a value someone will read as authoritative.
Two requirements follow that an ordinary project does not have. First, every value must have a provenance — the question “who decided this” has an answer, and the answer is not “that is how it came to be”. Second, knowledge passes an authorization loop before it becomes trusted and published on a consumption surface; a computed value and one typed in by hand are different things, and the difference shows not in words but in the carrier.
What changes when the agent does not have you
The most important change is the environment. While the agent works in your terminal, your check is built into the process by itself: you see the output, you interrupt the agent, you can correct it. Inside a closed perimeter none of that is there. The human is left with a personal cabinet, the agent with a package of assignments, and everything the normative documentation requires of a human is brought out onto a button in the control panel.
The supports become visible that in personal work rested on you: the two-phase run with a gate between plan and execution, the verification apparatus, the observability of a run, the answer budget, the data boundary. This is not bureaucracy laid over development — it is what stands in for the human who is not inside the perimeter.
Both courses use the HealthOS platform as a running example, but the techniques transfer: a closed perimeter and the provenance of a value are needed wherever the result is socially significant and letting an agent loose is simply not admissible.
Course 3 · Executable knowledge as the subject of development
Why you need this course. In a regulated environment the subject of development is not code but knowledge, which is turned into executable code by stated rules. Responsibility for the result is different here, and the habits of an ordinary project carry over at too high a price.
What you will learn. Development in a regulated environment: the normative corpus and global conventions, repositories and the boundaries of authority, developing components with agents, the platform MCP servers, gathering knowledge. Extending an existing domain: a program in the ASL language, the authorization loop, domain research and the research document, the provenance of values, calibrating thresholds, a new consumption surface and the analysis of a real divergence. Standing up a new domain: the boundary between the invariant core and the changeable dialect, a seven-step route and a list of prerequisites that no amount of declaration-writing will create.
What you gain. You understand where an authoritative value comes from, and why the question “who decided this” must have an answer.
How it is built. Three chapters, 20 lessons, every lesson ends with three tests and explanations. Prerequisites — the first two courses.
Course 4 · The HealthOS development environment
Why you need this course. The preceding courses teach you to work with agents that have you: your terminal, your browser, your prompt at any moment. Here you have only a web interface in a personal cabinet, and the fleet of agents has your package of assignments.
What you will learn. The configuration of the environment: why a closed perimeter is needed, what the configuration is made of, how the gates and topologies work, what the alternatives cost, what the MCP servers give. The foundations of a run: the classes of defect and the protection against them, instruments, access and requests, the lifecycle of a resource and the distribution of norms, the task package, the two-phase run and the verification apparatus. Boundaries and traces: what is specific about managing context here, behaviour without a human, the data boundary, roles and secrets, the observability of a run, the answer budget — and an honest account of what does not exist yet.
How it is built. Three chapters, 20 lessons, every lesson ends with three tests and explanations. Prerequisites — the three preceding courses. The course describes the target state of the environment and is published together with it.
The preceding step is the introduction to working from a specification: two courses tied to neither the platform nor any domain.