The Short Answer
Capable open-source agents are already free: ByteDance's MIT-licensed DeerFlow 2.0 reached #1 on GitHub Trending on 28 February 2026, and IFM's Apache-2.0 K2 Horizon fleet spans 0.9B to 375B parameters. Neither ships K-12 governance. A district needs five layers before deployment — dual-layer moderation, FERPA and COPPA by design, complete audit trails, grade-band behaviour, and SSO. With ibl.ai you own all the code and the data.
The software is free. The governance around it is the entire cost, and it is not in the repository.
What open-source agent software actually shipped for K-12 districts, and when did it ship?
Two releases are doing most of the work in this conversation, and both are routinely described with the wrong date or the wrong scope.
DeerFlow is ByteDance's MIT-licensed agent harness, which orchestrates sub-agents, memory and sandboxes across tasks that run for minutes or hours.
It was not open-sourced this week. Version 2 is a ground-up rewrite of a project whose 1.x line predates it, and the repository records that DeerFlow claimed #1 on GitHub Trending on 28 February 2026 following that launch. It currently carries roughly 82,000 stars.
K2 Horizon is IFM's model fleet — six Apache-2.0 models from 0.9B to 375B parameters, published on 3 September 2026.
It is frequently summarised as uniformly "fully open," and that is not accurate today. The 375B model card states plainly: "We have released the final checkpoint; intermediate checkpoints, along with the data and the training code, will be released."
Only the 3.7B and 7B ship training code and data today; the 0.9B, 32B, MoVA-36B and 375B publish weights with the code and data still promised — and the 32B has not released a final checkpoint at all. We covered what a fully open model fleet changes.
Neither correction weakens the point for a district. Both correct the urgency: this has been true for months, not since last week.
Why does a free, capable agent change a K-12 district's risk profile?
Because the constraint that used to slow adoption was budget approval, and budget approval was also where governance questions got asked.
A commercial K-12 AI tool arrives through procurement. Someone reads the data processing agreement, someone asks where student data is stored, and the district's answer to a parent is written before the first login.
A downloadable agent skips all of it. A capable teacher or a curious IT administrator can stand one up in an afternoon with no purchase order and therefore no review.
The behaviour also differs from the chatbot most district policies were written against. An autonomous agent does not wait to be prompted — it plans, retrieves and acts across whatever systems it can reach.
Pointed at a student information system or a shared drive, it enlarges the surface for accidental disclosure rather than answering questions about it.
That is a different control problem from "which website may students visit," and it is why K-12 AI governance cannot be borrowed from enterprise templates written for adults who can consent.
Which five governance layers does a district need before running an open-source agent?
Five, and no open-source repository ships any of them.
Dual-layer content moderation. Every input screened before the model sees it, every output filtered before the student sees it, with both layers configurable by grade band (K-2, 3-5, 6-8, 9-12) and subject. A single filter on the output is the common shortcut and it leaves the prompt side unguarded.
FERPA and COPPA enforced in architecture, not in policy. Student data that never leaves district-controlled infrastructure, no student interactions used for model training, configurable retention, and a verifiable parental consent workflow for students under 13.
Complete audit trails. Every interaction logged, timestamped and tied to an identity, exportable for a board meeting or a parent request. A log a district cannot export is a log it cannot answer with.
Age-appropriate behaviour by grade band. Vocabulary, topic boundaries, tone and escalation should differ between a seven-year-old and a seventeen-year-old automatically, as a property of the deployment rather than a setting each teacher remembers to apply.
Identity and SSO integration. Authentication through the providers the district already runs, with permissions that distinguish students, teachers and administrators.
What do FERPA and COPPA actually require of a district running an AI agent?
Two different statutes with two different subjects, and an agent deployment touches both at once.
FERPA was enacted in 1974 as section 444 of the General Education Provisions Act. It gives parents and eligible students four rights over education records.
Those are the right to inspect and review the records, to seek amendment of records they believe are inaccurate, to consent to disclosures of personally identifiable information, and to file a complaint with the Department of Education.
Rights transfer to the student at 18, or on enrolling in a postsecondary institution, whichever comes first, so in K-12 they are held almost entirely by parents.
The operative word for an agent deployment is records: if the agent reads them, generates them, or logs them, the resulting artefacts sit inside that framework.
COPPA applies to online services directed to children under 13, and to operators with actual knowledge that they are collecting personal information from a child under 13.
The Rule text was last updated in the Federal Register on 22 April 2025, and the FTC issued an enforcement policy statement on age-verification technologies on 25 February 2026.
For an elementary deployment, verifiable parental consent is not a checkbox at the end of the project. It is a workflow the platform has to support before the first student logs in.
Districts working through that specifically should read our note on COPPA-compliant AI for schools.
Should a district build the governance layer itself or deploy it as infrastructure?
A district with a strong engineering team can build it. The question is whether that is the right thing for that team to be maintaining.
Building means owning moderation calibrated per grade band, a consent workflow that survives legal review, an audit store with a retention policy, and SSO integrations.
It also means re-validating all of it every time a model or a regulation changes. We have not seen a credible published estimate of how long that takes across districts, so we will not offer one. The maintenance, not the build, is the part that never ends.
The alternative is to treat governance as infrastructure the district owns rather than software it writes, and to keep the model layer replaceable underneath it.
That framing also removes the cost trap. Per-student pricing is the wrong shape for a district, because it multiplies with enrolment regardless of how much any student actually uses the system.
How does ibl.ai give a K-12 district governed open-source agents?
By shipping the five layers as the platform, and leaving the model choice open underneath.
With ibl.ai you own all the code and the data. The district receives the full source code and runs the platform on its own infrastructure, so student data stays inside district control.
The platform is model-agnostic across any LLM, so an open-weights fleet or a hosted frontier model are both just configuration. Pricing is usage-based with no per-seat pricing.
It will deploy anywhere, from the district's own cloud to on-premise or a fully air-gapped network.
The governance layers are built in rather than assembled: dual-layer moderation configurable by grade band, FERPA and COPPA compliance by design with configurable consent and retention, logged and exportable interactions for board reporting, and age-appropriate responses across K-2, 3-5, 6-8 and 9-12.
Integration is through what districts already run: LMS access via LTI for Canvas, Schoology, Google Classroom, Blackboard, Brightspace and Moodle, SIS connectors for PowerSchool, Infinite Campus and Skyward, and SSO through Clever, ClassLink, Google and Microsoft.
The 12 K-12 agents cover tutoring, lesson planning, assessment, special education, student safety, family communication and district administration.
1.6M+ users across 400+ organizations run the platform this way, including NVIDIA, MIT, and Syracuse University.
ibl.ai is family-owned and operated from New York, NY.
Related reading: K-12 AI agent governance can't be borrowed from enterprise — why controls written for consenting adults under-specify for minors, and what a fully open model fleet changes.
Sources: DeerFlow's licence and the 28 February 2026 GitHub Trending placement from the bytedance/deer-flow repository; the K2 Horizon 375B licence and pending training-code release from its Hugging Face model card; FERPA from the U.S. Department of Education; COPPA from the Federal Trade Commission.