Principles of a Trusted portable learning context
Proposed principles for defining and assembling educational data into a portable, policy-aware artifact that institutional source systems can stand behind for multi-agentic workflows.
Changelog
Changelog entries are not listed yet.
Abstract
Agentic workflows in education raise an interoperability problem that data exchange standards alone do not solve. When AI agents act on behalf of learners or educators, across systems and institutional boundaries, each agent needs a shared, time-bounded, policy-aware view of the situation. Traditional learning-data interoperability moves records between source systems and authoritative consumers. Agentic workflows demand something different: a runtime, composable, governed structure that any agent can read, verify, and act on without re-deriving consent, inference, or sovereignty rules each time.
This paper sets out the principles of a trusted, portable learning context tplc. A tplc is a recipe for assembling educational data the community already maintains into a portable, policy-aware artifact that institutional source systems can stand behind. It is not a new data standard, not an agent's memory store, and not a replacement for existing vocabularies. The work is a fresh, cross-cutting endeavor across the 1EdTech community, sitting above current specifications and binding them to agent-mediated learning. The paper describes the architectural position, the six core properties (consent, sovereignty, provenance, realtime, querying, and multi-source composition), and the new class of education platform that compiles, governs, and serves these artifacts.
Status of this document
This is a Public Comment Draft positioned as a principles paper. Its purpose is to establish shared language and shared properties for trusted, portable learning context tplc ahead of a hackathon and ahead of any formal charter. The companion technical RFC (Part 2) will propose technical patterns, data models and standards for consideration across the 1EdTech community. This document is non-normative.
How to comment
Comments, redlines, and counter-proposals are invited via the discussion channels listed at the project URL above. The Open Questions section at the end of this document enumerates the points where community input is most needed.
1. Motivation
This section sets out the problem that motivates a trusted, portable learning context tplc, and the gap that existing patterns leave open.
1.1 The context-failure problem
When an AI system in education does not have enough context, it falls into one of three failure modes. It refuses ("I cannot help with that"), it generalizes (a plausible answer that is wrong for this learner, this course, or this jurisdiction), or it hallucinates (a confident answer with no grounding in the institution's data). Each of these is observed in production today, and each erodes trust faster than improved model quality can rebuild it.
These are not model failures. They are context failures. The model does not understand the situation, cannot see what matters, or does not know the boundaries that apply. The fix is not a larger model. The fix is a defined, governed, time-bound description of the learning situation that the model is acting within.
1.2 Why this matters now
Three forces converge in 2026 to make this problem urgent.
AI is moving from chat to action. Until recently, AI in education was largely a single assistant answering a single question; the interaction began and ended in one exchange. AI systems can now plan a sequence of steps, pull information from multiple sources, draft and revise material, and hand work to other AI systems, all in pursuit of one learner-facing task. The industry term for this pattern is the agentic workflow: several AI components participate in a single task, each contributing part of the work and passing context to the next. A workflow that helps a student prepare for an assessment, for example, may involve one agent retrieving the syllabus, another reviewing the student's prior performance, and a third drafting a personalized study plan. Every step depends on those agents seeing the same learner, the same course, and the same policy boundaries in the same way. Section 5.5 illustrates such a workflow in more detail.
Expectations have shifted in parallel. Educators, learners, and administrators no longer want a generic "AI assistant"; they want AI that knows their class, their learner, and their curriculum. That expectation cannot be met without trustworthy context.
The source-system contract that education currently depends on was not designed for either shift. The dominant integration pattern is request-and-respond data APIs scoped to a single resource, authenticated at the level of the institution rather than the learner or the moment, and refreshed by overnight or hourly batch synchronization. That contract serves system-of-record interoperability well. It cannot, in its current form, deliver a moment-bounded, learner-bounded context to an AI agent at the moment of action, nor carry that context safely from one agent to another.
This paper argues that the gap between what agentic workflows now require and what source systems can deliver is the central interoperability problem in education for the next five years. It proposes a pattern, called trusted, portable learning context tplc, to close that gap.
1.3 Goals of this paper
This paper sets out to do five things:
1.4 Non-goals
This paper is written to build consensus and enable community exploration, not to prescribe solutions. The intent is to put the principles of tplc in front of the community: source-system vendors, platform builders, institutions, learners, and standards contributors. A follow-up document will propose technical approaches once the community has been consulted on the principles set out here.
1.5 A multi-disciplinary, integrative effort
Trusted, portable learning context tplc sits at the intersection of disciplines that are normally addressed separately: the vocabularies that describe learning, the identity systems that establish who is acting and on whose behalf, the policy frameworks that capture consent and disclosure rules, the cryptography that lets recipients verify what they receive, the emerging protocols by which AI agents communicate, and the education domain itself. These communities span standards bodies such as 1EdTech, ADL, W3C, Schema.org, European Commission, and OpenID. No single body holds the whole picture.
1EdTech has convened cross-community conversations of exactly this shape for more than 20 years; this paper, and the follow-on work it points to, is another generation of that process. The contribution is integration, not new specification. The aim is a recipe and a coordination surface that let existing communities compose their work into a single, governed artifact, rather than yet another standard to maintain. Cross-community participation is, on that basis, a precondition rather than a courtesy.
1.6 Conventions
The capitalized terms "MUST", "SHOULD", "MAY", and their negations carry the meanings defined in RFC 2119 when they appear in this document. Their use here is illustrative; this draft is descriptive in nature, and binding conformance language will be the responsibility of downstream specifications.
2. What is a Trusted Portable Learning Context
This section establishes the working definition of tplc used throughout the paper.
2.1 Definition
A trusted portable learning context (tplc) is a structured, time-bound description of a single learning situation, assembled from authoritative sources, governed by the policies of the institution that owns it, and intended to inform an AI agent or application about who the learner is, what they are doing, why they are doing it, what information is relevant, and what constraints apply. A tplc gives an agent enough information to act, and no more. Holding that boundary requires explicit mechanisms for data control and governance that travel with the context, so that the institution's policies are clear and enforced wherever the tplc is used.
2.2 Qualities
Six qualities follow from this definition and are useful as design constraints.
A tplc is time-bound. It reflects a specific moment, not a permanent state. Two contexts compiled for the same learner one minute apart are different artifacts.
A tplc is situation-bound. The situation, not the data model, defines what information the tplc needs to carry. A tplc is assembled around what the agent must do, not around a comprehensive map of relationships across the institution's datasets. The same piece of data may be central in one context and irrelevant in another.
A tplc is broad, not deep. It spans many kinds of information (learner, course, curriculum, progress, achievements, accommodations) and takes a thin slice from each rather than deep records from any one of them.
A tplc is a compiled artifact. It is an assembled snapshot produced at a specific moment that can be shared across multiple agents. This is distinct from a live query against the institution's systems or a continuous stream of events, which are typically required to create the tplc.
A tplc carries only relevant information. Inclusion is filtered by what the situation requires, not by what the institution happens to hold. This is what makes consent and minimization tractable.
A tplc is dynamic and event-driven. Every meaningful interaction creates a new context. At scale, an institution will produce millions or hundreds of millions of distinct contexts.
2.3 Ingredients versus recipe
For 25 years, work in the global education community has agreed on the ingredients: learners, courses, skills, progress, credentials, accommodations, and identity. AI does not change those ingredients. What it changes is the recipe. A tplc is the recipe: a defined way of assembling the right ingredients to describe a specific learning situation, for a specific purpose, with a specific audience.
This framing is the central insight of the paper. The paper does not invent new vocabulary; it defines how to compose existing vocabulary into a new class of artifact.
2.4 What trusted portal learning context is not
A tplc is not a data standard in the traditional sense. It does not replace OneRoster, Caliper, CASE, OpenBadges, the Comprehensive Learner Record (CLR), or any other 1EdTech specification. It does not replace interoperability between systems of record, such as the data exchange between a Student Information System (SIS) and a Learning Management System (LMS). It is not a dataset, a warehouse, or a longitudinal record. It is not a profile of a single existing standard. It is also not an agent's session memory, a distinction expanded in Section 2.6. A tplc is a coordinating artifact that references and composes the existing standards for the duration of a single learning situation.
In particular, the notion of shared context is not the same as interoperability. Interoperability is about moving data between systems. Shared context is about describing what is happening right now. The two are complementary, not substitutes.
2.5 The meaning of "Trusted" and “Portable”
The two qualifiers "trusted" and “portable” each address a different institutional need. Trust answers what makes an institution willing to release a tplc in the first place. Portability answers how a tplc holds up once it is in use across many agents and many systems.
2.5.1 Trusted
Institutions are accountable for the data they release and for what is done with it. They will not release a tplc they cannot stand behind. A learning context is trusted when the data came from authoritative sources, the institution's consent and disclosure policies were applied before the context was released, the context describes a real situation at a real time, and, where the use case requires it, the context can be verified by the recipient. The four core properties in Section 4 explain how each of these is achieved.
2.5.2 Portable
Without portability, every agent in a workflow has to query the institution's source systems directly and infer its own view of the situation. At scale, this places an unsustainable load on systems that were not designed for it, and it leaves each agent with a slightly different understanding of the same learner and the same situation. A learning context is portable when it can be passed from one agent, system, or organization to another without losing its meaning, its governance, or its ability to be verified. Producing the context once and sharing it across agents removes the duplicated query load and the consistency gap.
2.6 tplc versus agent memory
A common position in the AI community holds that agent memory, typically a folder of Markdown files or a local database written and read by an agent, is sufficient as "context" for an AI. For chat-style assistants operating against a single user's notes, that position has merit. In education, the stakes are different. Agents will increasingly recommend learning pathways to students, generate instruction for them, and provide tailored support during their studies; the context an agent sees shapes what a student is recommended, taught, and supported with. For these institutional, regulated, multi-party use cases, agent memory is insufficient. Three conceptual differences distinguish a tplc from agent memory, and each will be reinforced with technical mechanisms in Part 2:
Memory stores have a place inside an agent's working scratchpad. They are not a substitute for a governed, time-bounded, provenance-aware artifact when the situation crosses an institutional boundary, and they are not what this paper proposes.
3. Architectural position
This section sets out where a tplc sits in the education software architecture and what it adds that existing patterns do not provide.
3.1 tplc and the agent stack
A tplc is the content an AI agent needs. The Model Context Protocol (MCP) and emerging agent-to-agent protocols are transports by which agents discover capabilities and exchange information. A tplc is agnostic to the transport. An agent can fetch a tplc over MCP, over a GraphQL endpoint, or over a REST API; the artifact is the same, and the trust properties travel with it.
1EdTech's ongoing work on best practices for MCP in education sits adjacent to this pattern. The two are complementary: MCP best practices inform how a tplc is exposed and discovered, while a tplc defines what is exposed.
3.2 What tplc adds that today's stack does not
Today's stack can move data between known systems, on a schedule, with system-level credentials. It cannot, without bespoke engineering, do any of the following: compile a learner-and-moment-bounded view across multiple sources at the moment of action, apply institutional disclosure policy at the point of release, attach the consent that authorized the release to the artifact itself, or make the resulting artifact verifiable to a third-party agent.
A tplc is the named pattern for delivering those four capabilities together. It also exposes a viable compile path from multiple real-time sources, which this paper treats as a first-class concern in Section 6.
3.3 The spectrum of agent consumers
The primary consumer of a tplc is an agent operating in or on behalf of an institutional or market system: an LMS-embedded tutor, a curriculum-mapping service, an analytics dashboard, an admissions assistant. The pattern must also accommodate agents that run on personal devices, including agents on a learner's phone, laptop, or wearable. A personal-device agent often knows the learner's situation, preferences, and goals more intimately than any institutional system, because it is closer to the learner's daily life and is not bound to a single institution.
Personal-device agents are not the primary use case for this paper, and future work should not optimize the architecture for them at the expense of institutional control. The architecture should equally not design them away. Some of the most context-aware learner support in the next few years is likely to run on personal devices, and the pattern is more durable when it accommodates that case from the start. A tplc released to a personal-device agent is subject to the same consent, sovereignty, and (where applicable) provenance properties as any other consumer; the institution's policy engine evaluates the request, the filtered projection is computed at the source, and the artifact crosses the boundary on the same terms.
The presence of a personal-device tier of consumers strengthens, rather than weakens, the case for the policy and projection mechanisms in Sections 4 and 5. The same is true at scale, which Section 6.8 treats as a first-class concern.
3.4 A new class of system: the tplc service
The architecture in this RFC implies a new class of system in education infrastructure. A tplc service is a platform whose responsibilities are: to compile context from multiple source systems on demand; to organize the result into tplc artifacts at the right grain; to apply the institution's governance and consent policy at the moment of release; to expose a query interface to agents and applications; and, where the use case requires it, to sign the resulting envelope with verifiable provenance.
A tplc service is not a Student Information System, a Learning Management System, an Identity and Access Management platform, an assessment platform, or a credential platform. It depends on all of them as sources, but its function is distinct. It is the coordinating layer between the systems of record and the agentic workflows that require context across them, and it is the layer at which the four core properties of Section 4 are realized.
Several deployment models are plausible. An institution may host a single tplc service that fronts all of its source systems and serves all of its consumers. A ministry or sector body may operate a regional tplc service on behalf of multiple institutions. A market vendor may offer a hosted tplc service that institutions configure and govern. The architecture is agnostic to the deployment model, provided the trust properties are preserved.
The introduction of a new system class is significant for the education software market. The tplc service is where the compile, governance, and query work concentrates, and it is the natural integration target for both the source-system contracts of Section 6 and the agentic-workflow consumers of Section 3.3. Future working groups may need to consider whether to publish a conformance profile for tplc services as a deliverable separate from the source-system and consumer profiles.
3.5 Layered architecture at a glance
The architectural position of tplc reduces to three layers with the tplc service as the coordinating tier between systems of record and the agents that consume context.
Figure 1. The tplc service sits between source systems of record and consumer agents, applying the core properties of Section 4 at the point of release.
4. Core properties of a tplc
Section 2.2 described the qualities a tplc should have as an artifact: time-bounded, situation-bounded, broad, compiled, selective, and dynamic. The properties in this section follow from those qualities as logical implications for the producing service. If the artifact is to behave as described, then the service that compiles and releases it has to commit to a coherent set of behaviors at the point of release.
Six such properties are emerging in current working-group discussion: consent, sovereignty, provenance, realtime compilation, querying, and composition across multiple data sources. They are offered in this paper as candidate properties for review, not as a settled list. Their scope, their interactions, their relative priority, and whether the set is complete are matters for the community to decide and validate during the public comment period and the working-group activity that follows.
4.1 Consent
A tplc carries only what the institution's consent policy permits to be released for the purpose at hand. Consent is not a banner the user clicks; it is a deterministic filter applied to the candidate context before release, evaluated against the purpose, the requesting agent, the learner's preferences where applicable, and the institution's standing policy.
In multi-recipient cases, a single canonical tplc can be projected through different filters for different agents, so what each recipient sees varies while the underlying context graph remains stable; this projection mechanism is described in Section 5.3. The policy model is sketched in Section 10 and the full specification is deferred to future working-group output.
4.2 Sovereignty
The institution that owns the context owns the policy. Sovereignty means the consent policy is enforced at the source, deterministically, by the institution's own infrastructure, and is not delegated to a downstream vendor or model provider. This property is what allows a ministry, a university, or a school to participate in cross-border AI use cases without surrendering control of its data.
4.3 Provenance
When a use case requires it, a tplc can be cryptographically signed so that a downstream consumer can verify who compiled the context, from which sources, under which policy, and at what time. Provenance is an optional layer because not every use case justifies its operational cost: a low-risk in-product AI assistant inside a single LMS may not need a signed context, while a cross-institutional credential decision almost certainly does. The candidate signing approach, based on W3C Verifiable Credentials Data Integrity, is described in Part 2, Section 11.
4.4 Realtime
A tplc is compiled at the moment of action, against the current state of the institution's source systems. Stale context is one of the failure modes Section 1 named; realtime compilation prevents it by ensuring that what an agent sees is what is true now, subject to the time bounds the institution attaches.
Realtime compilation places real demands on the tplc service, which must query multiple source systems on demand, apply institutional policy at release time, and return a coherent artifact within the response budget an agent can tolerate.
4.5 Querying
A tplc is requested by an agent rather than pushed by the institution. The agent expresses the situation it is operating in, the learner involved, the purpose it serves, and the information it requires; the tplc service compiles a response that matches the request while staying within institutional policy.
The querying property is what makes a tplc usable in agentic workflows. Without it, the agent would have to know in advance what the institution holds and how to ask for it. The query interface lets the agent surface its need; the policy engine decides what can be answered.
4.6 Composition across multiple data sources
Education data is distributed by design across systems of record: student information systems, learning management systems, assessment platforms, identity providers, credential platforms, and curriculum systems. A tplc composes information from across these sources into a single artifact, and the consumer does not need to know which source contributed which fact.
This composition is what makes a tplc useful in the typical fragmented education landscape. Bringing related information together from heterogeneous sources gives the agent a coherent picture of the learning situation rather than a per-system fragment of it. How that composition would be achieved, and what substrate would best support it, are open questions for community investigation.
4.7 How the properties compose
The six properties are designed to compose. Consent decides what is in the artifact. Sovereignty decides who applies consent. Provenance, when present, makes the result verifiable to anyone who later reads it. Realtime compilation makes the artifact relevant to the moment. Querying makes it usable in agentic workflows. Composition across multiple data sources makes it useful in the institutional landscape it must serve. Together they form a candidate set of commitments for a tplc service. The boundaries between them, their dependencies, and whether the set is complete are open questions for community review.
flowchart TB subgraph trust["Trust commitments"] direction LR CONSENT["Consent<br/>(what may be released)"] SOV["Sovereignty<br/>(who enforces policy)"] PROV["Provenance<br/>(verify origin & policy)"] end subgraph ops["Operational commitments"] direction LR RT["Realtime<br/>(compile at action time)"] QRY["Querying<br/>(agent expresses need)"] COMP["Multi-source composition<br/>(one coherent artifact)"] end trust --> ART["tplc artifact"] ops --> ART ART --> AGENT["Agentic workflow"]Figure 2. The six core properties of a tplc service. Consent, sovereignty, and provenance describe the trust commitments; realtime, querying, and multi-source composition describe the operational commitments.
5. The tplc as a coordinating artifact
This section sets out how a tplc could coordinate the interests of producing institutions and consuming agents in a single artifact. The mechanisms discussed here are logical consequences of those interests, not commitments to a particular implementation. The community is invited to investigate them, experiment, and report back; the validated form of each mechanism is a matter for the working-group activity that follows this paper
5.1 A two-sided declaration
If a tplc has a defined shape, two declarations become possible that are difficult or impossible today. Institutions could declare what they allow: which categories of data may be released, to which classes of agent, for which purposes, and under which consent terms. Vendors and agent developers could declare what they need: which categories of data are required to perform a function, at which grain, for how long, and for what stated purpose.
A tplc would serve as the surface on which those two declarations meet. The institution's "this is what we allow" and the agent's "this is what we need" could be reconciled at the point the tplc is produced, and both sides could have a record of the decision. How that reconciliation should be structured, and how disputes between the two declarations should be surfaced and resolved, are open questions for community investigation.
5.2 Tiered disclosure as one pattern to investigate
Institutions already practice tiered disclosure informally; what could change is the surface on which the tiers are declared. One pattern worth exploring would be to treat each category of data as having multiple disclosure tiers, where the institution releases the lowest tier consistent with the agent's stated purpose. Learner information could range from "anonymous" to "profile within course" to "extended longitudinal record". Progress data could range from "completion status" to "progress indicators" to "detailed assessment results". Curriculum, achievements, and accommodations might follow similar logic.
The community will need to decide whether such tiers are useful in practice, whether they should be normative, and whether other approaches (per-field minimization, purpose-bound disclosure, capability-based release) would better serve the needs of institutions and agents. The tiers offered here are illustrative, not prescriptive.
5.3 Filtered projections per recipient
Institutions routinely need to release different views of the same situation to different recipients. A natural design might follow from this need: one canonical context per learning situation, projected through a recipient-specific filter at release. The institution would maintain a single coherent picture of what is true; the filter would decide what each agent sees.
This would separate "what is true about this learning situation" from "what does this particular recipient need to know about it". The first would remain stable across recipients and over time; the second would vary by audience and purpose. Filtering would be the runtime expression of the consent and sovereignty properties from Section 4: it would let the institution grant the minimum information sufficient for each recipient's stated purpose without recompiling from source for every consumer.
The specific mechanisms by which projections would be derived (what should be filtered, what should be redacted, when pseudonymous identifiers should substitute for direct ones, how time windows should be constrained) are questions for the community to investigate and to report back on.
flowchart LR subgraph src["Source systems"] direction TB SIS2["SIS"] LMS2["LMS"] CR["Credentials"] end src --> CANON["Canonical tplc<br/>(one graph per situation)"] CANON --> FILTER["Institution policy filter"] FILTER --> PA["Projection<br/>Agent A"] FILTER --> PB["Projection<br/>Agent B"] FILTER --> PC["Projection<br/>Agent C"]Figure 3. Compile once, project many. Source systems feed a single canonical tplc; the institution's policy filters that canonical artifact into recipient-specific projections, so the underlying graph stays stable while disclosure varies by audience and purpose.
5.4 Decomposable composition
A tplc need not be a single, monolithic artifact. A reasonable design would allow it to be composed from smaller pieces, each focused on one aspect of the learning situation: the learner's progress on one assignment, the alignment of one competency to a framework, the entitlements relevant to one resource, the accommodations that apply to one assessment. Smaller units would make institutional governance tractable at the grain that policy actually targets, since a teacher's accommodation needs would require finer-grained policy than a class roster, and a competency mapping would need different governance from a personal need.
Three practical consequences are worth investigating:
How fine the decomposition should be, what governance should attach to each unit, and how the units should compose at release are questions for the community to explore. The graph substrate discussed in Section 7 is one approach that could support such decomposition naturally; whether to adopt it, and whether other approaches would serve as well, are matters for community investigation.
5.5 Multi-agent workflows
Agentic workflows pass context across agent boundaries. Today's identity and authorization platforms are built around a per-request, per-agent model: each call is authenticated separately, and each agent's authorization is re-derived from the source. That model fits single-agent interactions well. It creates a structural tension with multi-agent workflows, where context needs to travel from one agent to the next without re-authorizing every step.
Figure 4. A representative multi-agent assessment-prep workflow: the institution compiles a governed tplc once; each agent in the chain receives the same time-bound, policy-filtered context rather than re-querying source systems.
If each downstream agent must re-derive consent and authorization from scratch, the result is either a leak (over-disclosure as context crosses the boundary), an unnecessary refusal (the next agent cannot tell what was authorized), or a workflow that cannot complete at all. A tplc that carries its policy decisions and, where applicable, its provenance with it could give the next agent in the chain something to verify rather than to recompute.
This raises a hard question for the community: how should multi-agent workflows reconcile the institutional preference for per-request, per-agent authorization with the practical need for context that can travel across agent boundaries? The question matters because of what the alternative implies. If every handoff required fresh authorization from the source, agent-to-agent workflows would not happen at scale.
The specific mechanisms (what should be embedded, what should be signed, how downstream agents would perform the verification, where the institution would re-engage the authorization flow) are open questions for the community. The principle is that a tplc could be what makes coordination across agent boundaries tractable; how that principle would be realized, and how it would coexist with per-request authorization where institutions require it, are matters for the working-group activity that follows.
6. Implications for source-system integration
This section sets out what a tplc would ask of the source systems it draws from, and how that differs from the integration contract education software runs on today.
6.1 The current de-facto contract
Education source systems today expose data through per-resource REST endpoints (often in OneRoster, an LMS-vendor REST API, or an SIS-vendor REST API), authenticated with instance-level service accounts, and synchronized to consumers on a schedule that ranges from realtime-best-effort to nightly. This contract was designed for, and works well for, system-of-record interoperability: keeping rosters in sync, exporting grades, posting outcomes.
6.2 Why the current contract breaks for a tplc
Compiling a tplc would strain every assumption of that contract.
A tplc would need to be assembled at the moment of action. Nightly batches, and even hourly syncs, would usually be too late for the learner-and-now use cases that motivate AI in education. Latency budgets would shift from hours to seconds.
A tplc would compose information from several systems for a single learner in a single situation. The current pattern requires the consumer to fetch from each source, reconcile identifiers, resolve cross-references, and apply institutional rules in their own code. That work is bespoke at every institution, fragile under schema drift, and a source of compliance risk.
A tplc would need to be authorized per request and often per user, not per integration. Today's instance-level service-account model gives a vendor "all the data" once installed, leaving the burden of minimization to the vendor. Sovereignty (Section 4.2) inverts that posture: minimization would happen at the source, per request, against the requesting principal.
The current contract has no native query surface. Resource-level REST allows a consumer to fetch a known resource by identifier; it does not allow a consumer to ask "for this learner, in this course, this week, which assessments are linked to which competencies?" without N+1 round trips and client-side joins.
6.3 The shift to query interfaces
A tplc compile path would benefit from a declarative query interface, schema-driven, that lets the consumer state the projection it needs in a single round trip. GraphQL is one well-understood candidate. Future working groups will need to decide whether to recommend a canonical query contract for tplc sources, or to remain transport-agnostic and define the artifact only.
6.4 The shift to realtime and event-driven delivery
A tplc reflects a specific moment in a learner's situation. If the underlying data is stale, the artifact is stale; if the artifact is stale, the agent acts on a picture of the world that is no longer true. Many source systems today deliver data on a schedule, overnight, hourly, or as periodic batches, because that pattern fits well with system-of-record reconciliation. For agentic workflows, where the moment of action and the moment of compilation are the same moment, that pattern is too slow.
A tplc would therefore depend on source systems exposing changes as they happen, in a form a compiler can consume close to realtime. The shape that realtime delivery should take is an open question. Future working groups will need to consider:
1EdTech has ongoing work on realtime delivery patterns for existing education vocabularies. That work would be complementary to a tplc: it could inform the transport layer beneath the artifact without prescribing what the artifact itself looks like.
6.5 Per-user, per-request authentication and authorization
MCP servers and agent integrations in production today typically authenticate at the level of the integration, not the user. For a tplc, the requesting principal would need to be discoverable and verifiable per request, so that institutional policy could be evaluated against it. This implies federated identity (OpenID Connect, SAML), delegation tokens, or capability-based credentials, rather than long-lived service-account secrets.
6.6 What this would ask of source-system vendors
The implications for vendors of student information systems, learning management systems, identity and access management, assessment platforms, and credentialing are concrete, though the specific mechanisms remain for the community to settle. Source systems that participate in a tplc would need to support, in some form:
None of these would obsolete the existing integration surfaces. They would sit alongside them, used by the AI use cases that need them while the existing surfaces continue to serve system-of-record reconciliation.
6.7 Migration posture
A tplc would be additive. Future working groups would need to assume that source systems will expose tplc-relevant capabilities alongside, not in place of, their existing REST endpoints, and would design conformance accordingly. A staged migration, in which institutions adopt tplc for AI use cases first and continue to use REST for system-of-record sync, would be the realistic path.
6.8 Scale: more agents than learners
A safe planning assumption is that there will be more agents than learners. A learner may have a tutoring agent in one product, a study-planning agent in another, a personal-device agent on their phone, and an agent embedded in each of several content tools, in addition to the agents that teachers, advisors, and administrators run on the same learner's situation. Each of these agents may request a tplc for the same learner at the same moment.
A naive realization of the pattern would expose institutional source systems to a multiplicative load of rich, expensive queries, most of them duplicative. Source systems that today serve a few thousand integrations would, under a tplc regime, face a request rate that scales with agents-per-learner rather than with learners alone. Future working groups will need to treat this as a first-class concern, not an operational afterthought.
Three mechanisms are likely to be needed. Compiled-context caching, in which the institution computes the canonical tplc for a learner-and-situation once and serves filtered projections from it for the duration of a short validity window (Section 5.3), would avoid recompiling from source for every requesting agent. Query deduplication and result memoization at the institution's compile boundary would reduce upstream load when several agents request similar projections. Capacity controls and per-agent rate limiting would protect source systems from misbehaving or runaway consumers without penalizing learners.
Each of these mechanisms would be implementable inside the architecture this paper proposes; none would require changing the artifact or the trust properties. The natural home for them would be the tplc service introduced in Section 3.4, which is the layer that would already mediate between source systems and consumers. They would, nevertheless, be prerequisites for deployment at the scales that agentic workflows in education are likely to reach.
7. Closing: an invitation to the community
The pace and scale at which AI is moving through education is unlike any prior technology cycle the community has navigated. The integration patterns that have served education software for the last 20+ years were designed for a world in which data moved between known systems on predictable schedules. They are now being asked to support a world in which AI agents act on behalf of learners across institutional boundaries, in seconds rather than hours, and at a scale where there are likely to be more agents than learners. This is a seismic shift, a changing of the gears, and it is happening fast enough that the community has to respond now to shape what comes next.
The community where this work is taking shape in education is 1EdTech. The purpose of this paper is to put the principles of a trusted, portable learning context tplc in front of that community for shared consideration. The paper does not prescribe a solution. It sets out the qualities a tplc should have, the properties that would follow from those qualities, and the implications for source systems and consuming agents. The form each of these would take is for the community to investigate, validate, and decide.
The next steps are concrete. The community will gather to shape the principles set out here, run early tests and explorations against them, and report back. A companion technical paper will follow later this year, setting out the architectures and patterns being proposed for tplc artifacts, tplc services, and the supporting substrate. That paper will be informed by what the community learns in the interim.
This paper is an invitation, not a conclusion. The right form for a tplc, the right placement of consent and sovereignty in practice, the right balance between per-request authorization and multi-agent workflows, the right transport patterns, and the right deployment models are all matters for community work. What this paper offers is shared language, shared principles, and a shared sense of why this matters: agents will increasingly recommend, instruct, and support learners, and the context they act on will shape what those learners receive. Building that context together, with the institutional trust it requires, is the work that follows.
8. Glossary of terms
The definitions below are maintained as a reusable segment so later publications on the same topic can share one glossary.
This glossary defines terms used throughout publications on the trusted portable learning context (tplc) pattern.