Ambient Education Initiative

We are about to build far too many AI tutors. Schools, universities, cohort courses and textbook companies will each add a conversational interface to their existing material. Education startups will combine a model, course content, retrieval and a system prompt inside a branded application.

Many of these products will be useful. A capable tutor can make explanations more accessible, answer questions without embarrassment and adapt its response to the learner in front of it. But usefulness does not automatically make the tutor durable infrastructure.

As foundation models improve, the conversational layer becomes easier to reproduce. A learner may also have a general-purpose agent that already knows their projects, previous conversations, goals, mistakes and working environment. Asking them to abandon that context and open another chatbot simply because they want to learn something may become increasingly unnatural.

The more capable the underlying models become, the less defensible the tutor itself becomes. The valuable layer moves elsewhere: to how learning is specified, constrained, observed and progressed.

That is the thesis behind the Ambient Education Initiative.

The AI tutor is probably the wrong abstraction

Most AI education products collapse three different things into one application: the model, the pedagogy and the interface. The model answers questions. A system prompt attempts to make it behave like a teacher. The application becomes the place where the learner is expected to learn.

That architecture made sense when intelligence was scarce enough to be packaged as part of the product. It makes less sense when capable models are available through every major interface. The learner's existing agent may know more about their context than a new education product ever will: their writing, projects, calendar, codebase, prior conversations and recurring mistakes.

Why should that learner leave a familiar environment whenever they want to understand something?

The long-term interface for education may not be an education product at all. It may be the agent the learner already uses for everything else. If that is right, education software needs to own something other than the chat window.

The LMS owns the wrong layer

The modern learning-management system is largely a database with pages attached. It knows who is enrolled, which module they opened, whether a video played, when an assignment was submitted and what score appeared on a quiz. Sometimes it records a mentor's comment.

This was valuable when distributing content and tracking completion were difficult operational problems. Those problems still matter, but they are no longer the most interesting part of the system.

A content-management system answers: What content exists?

An LMS answers: Who is enrolled, and what did they complete?

Neither reliably answers: How should this person learn this thing?

That requires a different system. I call it a Learning Protocol System.

A Learning Protocol System does not primarily store lessons. It stores learning logic: the sequence, dependencies, actions, evidence, evaluations, constraints and interventions through which a learner progresses.

The future LMS may therefore have no learner-facing interface of its own. It could become a protocol layer underneath the interfaces learners already use.

Pedagogy should become executable

Good educators already think in protocols, even if they do not describe them that way. They begin by establishing what a learner understands, choose an explanation suited to that learner's context and resist giving away the answer before an attempt has been made. They watch for particular misconceptions, prescribe different exercises depending on what appears and ask for evidence before allowing the learner to progress.

That is an algorithm, not because teaching is mechanical, but because good teaching contains sequence, judgment, conditions and intervention.

When education is digitized, much of this logic disappears. We preserve the slides, videos and reading material. Sometimes we preserve an assessment rubric. But the reasoning that tells an educator when to explain, when to wait, when to challenge and when to intervene usually remains trapped in the educator's head.

Language models create the possibility of preserving that layer. They can interpret fuzzy instructions, examine a learner's response, adapt an explanation and invoke tools. This does not mean they can teach perfectly or operate without oversight. It means an educator can begin to express instructional judgment in a form that a sufficiently capable agent can execute.

Pedagogy can become executable without becoming entirely deterministic. The educator defines the progression logic and its boundaries; the agent decides how best to communicate within them.

That is more consequential than building another AI tutor.

A learning protocol is a state machine, not a course outline

A course outline describes what material comes next. A learning protocol must also describe why the learner is allowed to move there.

PauseReplay

The protocol might contain learning objectives, prerequisite relationships, diagnostic rules, explanation strategies, tasks, evidence requirements, rubrics, known misconceptions, remediation paths, mastery thresholds, human-review gates, safety boundaries and completion conditions. It should also be versioned: when an educator changes the protocol, the system should know which learner experienced which version.

These components do not all belong to the same kind of system. Some decisions should be deterministic. Some can be probabilistic. Some should be left to the model. Others should require a human.

That separation matters. An agent can have considerable freedom in how it communicates without being free to decide what counts as progression.

Agents should execute pedagogy, not invent it

Consider the apparently simple request: “Teach me product management.”

The model must decide what the learner should study, in what order, at what depth and through which exercises. It must judge whether an answer is sufficient, when the learner should move on and what expertise should look like. Instruction and curriculum design are delegated to the same stochastic system.

Sometimes this works remarkably well. Sometimes it produces a confident educational improvisation.

A Learning Protocol System separates those concerns. The educator defines the protocol. A runtime maintains learner and protocol state. The agent interprets that state and executes the next permissible action.

Replace a text model with a voice agent, an augmented-reality interface or a school application. The protocol and learner state remain. The interface can change without forcing the educator to rebuild the learning experience.

The protocol survives the interface. That is the point.

Education becomes ambient when learning enters the work

The strongest tailwind behind this idea is not a particular education technology. It is the proliferation of agents: general assistants, coding agents, workplace agents, browser agents, voice agents, personal agents and domain-specific agents.

If capable agents become part of the environments where people already act, education will be pulled into those environments too. Learning to code can happen while coding. Learning sales can happen while selling. Learning management can happen while managing. Learning finance can happen while analysing a business.

This is what makes education ambient. The educational system does not disappear; it moves underneath the activity.

The old pattern separates learning from its application. An ambient system keeps the learning protocol inside the execution environment.

The agent can observe the work, introduce an exercise, request evidence and route the learner toward help without requiring a separate educational destination. The protocol, rather than the agent's improvisation, determines what the intervention is trying to accomplish.

The portable artifact is the protocol

Today, an educator usually ships a course. Tomorrow, they may ship a protocol.

Imagine a negotiation protocol created by someone who has spent twenty years negotiating enterprise contracts, or a debugging protocol designed by an exceptional engineer. The valuable artifact would not be limited to their content. It would include their sequence of judgment, exercises, gates, common failure modes, heuristics and criteria for progression.

Their pedagogy becomes machine-executable.

The representation does not literally need to be learning-protocol.yaml. The important change is that the instructional logic becomes portable across interfaces, models and institutions. A protocol can be inspected, versioned, combined with other protocols and improved without rebuilding every application that uses it.

That makes pedagogy composable in a way courses rarely are.

Education needs protocols more than portals

For two decades, education software has been organized around portals: student portals, faculty portals, cohort portals and course portals. The underlying assumption was simple. If something important is happening, bring the user into our software.

Agents invert that assumption. Software increasingly goes to the user.

A learner should not have to navigate Dashboard → Course → Module → Lesson → Assignment merely to discover what they should do next. They should be able to ask the agent already present in their work. But the answer should come from a defined learning protocol, not from the model inventing a plausible curriculum in the moment.

This requires headless education infrastructure: learning capabilities that exist independently of a learner-facing application. The system might expose an API, SDK, MCP server, event stream, webhook and explicit permission scopes. A dashboard would remain useful, but it would become one client among many.

An agent could ask:

get_current_learning_state()
get_next_allowed_action()
submit_evidence()
request_evaluation()
get_feedback()
request_human_review()

An educator could publish a protocol, update a rubric, inspect failure patterns, review escalations or override state. The interface would no longer define the system's boundaries.

Composability changes how programs are assembled

Courses are usually monoliths. A six-week program is authored, packaged and sold as one unit. Replacing one part often means revisiting the entire experience.

Protocols could be composed instead. A founder program might combine components for customer interviews, market sizing, prototype testing, pricing and storytelling. Each component could have its own maintainer and stable contract. A school could assemble a program from protocols created by different experts; a company could replace one component without rebuilding everything around it.

Software has accepted this kind of composability almost everywhere else. Education still behaves largely like packaged desktop software.

The benefit is not modularity for its own sake. It is the ability to improve a learning mechanism independently while preserving the learner's broader path.

Learner state must outlive the interface

Portable protocols solve only half of the problem. The harder layer may be learner state.

Today, every education system creates another partial version of the learner. A university knows one version; a course platform knows another; an employer, coach and general-purpose agent each know something else. None holds a coherent, permissioned representation of what the learner understands, attempted, struggled with or demonstrated.

Ambient education needs learner state that can move without becoming public. It does not necessarily need to be centralized. It should be permissioned, partially private and, where practical, controlled by the learner. But it must be interoperable enough that changing an interface does not erase the learning process.

Moving from Claude to ChatGPT should not mean restarting the course. Changing schools should not erase prior evidence. Changing models should not discard the educator's pedagogy.

The protocol and state should outlive the interface.

Agent-native education requires explicit permissions

Adding an agent to an LMS is not the same as designing infrastructure in which agents are first-class participants.

An agent-native system should expose structured capabilities rather than forcing agents to click through pages. It should distinguish permission to read a protocol from permission to read learner state, submit evidence, evaluate evidence, modify the protocol or override progression.

Not every agent should receive every permission. A learner's personal agent may submit work. An evaluator agent may assess it. An educator agent may inspect patterns. Only a human educator may be allowed to alter the protocol or resolve a high-stakes review.

This starts to look less like an LMS and more like an operating system for learning. That comparison is useful only if it makes the boundaries more explicit: capabilities, state, permissions and processes must be legible to both people and agents.

Fail-safe does not mean deterministic

Education cannot become one giant workflow automation. Learners misunderstand things in unexpected ways. They sometimes need a different explanation, a step backwards or room to explore. Language models are valuable precisely because they can respond to that ambiguity.

The goal is not to remove model autonomy. It is to place that autonomy inside explicit boundaries.

This is what I mean by fail-safe: not a scripted tutor, but a constrained intelligent executor. The protocol should identify where variation helps and where it creates unacceptable risk.

Evidence matters more than completion

Completion is a poor proxy for learning. Watching a video, opening a lesson or clicking “done” proves very little. Even a multiple-choice answer often provides weak evidence of what someone can do.

An agentic system can work with richer evidence. Someone learning user research might submit interview transcripts. A learner developing software might submit a repository. Sales practice could produce call recordings; design practice could produce an artifact and its iteration history; writing practice could produce successive drafts.

The protocol can specify which evidence is expected, how it should be evaluated and what happens when it is insufficient or ambiguous. Progression becomes a consequence of demonstrated work rather than recorded consumption.

PauseReplay

That is closer to how expertise develops, and it changes what education infrastructure must be able to observe.

Educators become protocol designers

If this thesis is right, educators gain a new medium. Alongside books, courses, workshops and curricula, a new category may emerge: the protocol designer.

Their task is to translate expertise into a system that agents can execute without stripping away judgment. They must specify where flexibility helps, where constraints matter, how failure appears, what evidence counts, when to escalate and which sequence creates understanding.

The best protocol may eventually be more valuable than the best collection of videos. It captures not only what the educator knows, but how they help another person come to know it.

That is a future I find more interesting than replacing teachers with chatbots.

Models improve; protocols remain

Model capability will change rapidly. A tutor built tightly around today's model and interface may become technologically unremarkable within a few generations of releases.

A high-quality learning protocol can survive those changes. A newer model should execute it more effectively without forcing the educator to rebuild the learning experience. The same protocol could be used by a frontier model, a local model, a voice agent or an interface that does not yet exist.

Education companies historically had to create or procure nearly every layer themselves: content, assessment, interface, personalization, analytics and communication. Foundation models are absorbing a large part of the intelligence layer. Competing with that layer directly seems less useful than owning what remains scarce.

The scarce layer is the curriculum, pedagogy, learner state, evidence, trust and human judgment. Model providers can compete over intelligence. Interface companies can compete over interfaces. Education should own the learning logic.

What still needs to exist

Ambient education depends on infrastructure that is incomplete or does not yet exist. We will likely need an open learning-protocol specification, an authoring environment, a runtime, portable learner-state primitives, an evidence model and explicit permission scopes for educational agents.

We will also need versioning, evaluation infrastructure, human escalation, observability and auditing. Protocol registries, marketplaces or credentials attached to demonstrated evidence may follow, but they are secondary to making the core learning loop reliable.

There are many unresolved questions. How should a protocol express human judgment without pretending it is deterministic? Who controls learner state? Which evidence can safely travel between institutions? How do we audit an agent's execution of pedagogy? What should remain deliberately unportable?

Those problems are not a reason to retreat to another chat interface. They are the reason this direction is worth exploring.

An initiative, not one product

At AI Garage, I want the Ambient Education Initiative to be an umbrella for exploring this direction rather than the name of one application.

The infrastructure should be:

• Headless: learning capabilities exist independently of a learner-facing interface.
• Composable: programs can be assembled from reusable protocols and components.
• Interoperable: protocols and permissioned learner state can move across systems.
• Agent-native: agents participate through explicit, structured capabilities.
• Fail-safe: model autonomy operates within educator-defined constraints.

AI Garage's own programs give us a practical place to experiment because we can examine both the learning experience and the infrastructure underneath it. The first experiment may be a protocol, an MCP server, a state machine, a Claude session, a WhatsApp agent or a human-review gate around a real-world task.

If those primitives work, the interface can come later. Perhaps it never needs to become the center of the system.

From AI GarageHow we thinkThe working principles behind how AI Garage approaches ambiguous problems, learning, and building.

The bet

My bet is that education will follow the architectural shift already taking place across software. Interfaces will become thinner, agents more capable, capabilities more programmatic and state more portable. Applications will no longer need to own the learner's entire experience in order to participate in it.

Education is unlikely to be exempt from that shift. If learning moves into the environments where people already work, the durable system will not necessarily be the portal they visit. It will be the protocol that determines what should happen next, what evidence is required and when a human needs to intervene.

The Ambient Education Initiative is an attempt to test that proposition in practice. Can pedagogy be made portable without flattening it? Can agents execute it without being allowed to invent the criteria for progression? Can learners change interfaces without losing their state, evidence or path?

If those questions have useful answers, the future LMS may not have a learner-facing interface at all. It may become a learning-protocol layer underneath whichever interface the learner already uses.

Don't build another AI tutor. Define how something should be learned, and let any capable tutor follow the protocol.

If you want to test these ideas in practice and help shape the first experiments around ambient education, you can join AI Garage.