Skip to Main Content

Shamuel Perez

Built at Meta Global AI Developer Hackathon · Oct 26, 2026 · Remote

Shamuel Perez — Demo video

DISMODO is an adaptive learning engine for builders and AI agents. It is live at https://dismodo.org. Learning something new can be hard even when you want to. Often the idea isn't the problem: the example is unfamiliar, a step is too big, or a small confusion keeps repeating. Too often one struggle becomes an identity: "I'm bad at math." Imagine a public school classroom in the Dominican Republic, where a single teacher can have up to 50 students. Explaining square roots to each of them one by one is almost impossible. With DISMODO, the teacher sends the topic once. Every student then gets something like a "shadow teacher" of their own: explanations, examples and practice that adapt to what that particular student shows they need. One student gets a familiar example, another gets smaller steps, another a contrast with the mistake they keep making. When the session ends, the teacher sees who has really understood, checked on new problems without hints. They can move those students on to exercises and spend their own time on the ones who still need them. Builders describe what to teach and how to check it in a versioned experience package: - the objective - the activity and a deterministic evaluator - familiar contexts - known confusions - the reviewed explanations that are allowed DISMODO runs the session and adapts the support to the evidence. Then it returns a report of what was observed, what was interpreted and by whom, what the learner said, and what has not been checked yet. Example: a learner taps "I don't know this example", and the same problem comes back in a world they know. The example changes; the goal doesn't. Later they answer wrong while saying they're sure, right after an explanation. The engine escalates that moment to a stronger model, which picks a contrast from the moves the package allows. The learner can disagree with the hypothesis; their words guide the next step but never change a grade. New problems held out from practice then check whether the learning transfers. It isn't a chatbot or a course catalog. It's infrastructure that other products embed under their own brand, through: - a REST API and a TypeScript SDK - a <dismodo-session> Web Component - an MCP server, so AI assistants can find an experience, start a session and read the evidence A second product, Acme Onboarding, runs on the same engine with its own brand, key and package, and needed no engine changes. Describe your use of Meta products to build the submitted project Meta models are inside the product and were part of how it was built. 1. Muse Spark 1.3 (Meta Model API): the routine decision tier. - After each relevant learner action, Spark receives the session's evidence and the package's limits. - It returns structured JSON choosing one intervention and one confusion hypothesis, both from closed lists defined by the package. - It runs at minimal reasoning effort with an 8-second budget. In our runs a decision took about 2–6 s. 2. Muse Wonder 1.0 (Meta Model API): the critical tier, for the moments that matter most. - The learner rejects the hypothesis. - The same mistake happens twice. - The learner is confident but wrong right after an explanation. - Each session is capped at two critical calls. 3. Muse Wonder as a package author. A builder can paste their notes and Wonder drafts a complete experience package, with Spark as a fallback. The engine validates the draft, Wonder repairs it once if needed, and nothing is stored or published without human review. Live drafts took 10–21 s and produced valid packages. 4. Muse Code (with Muse Wonder) as a second engineer. It worked from written task specs in isolated git worktrees. It built: - the TypeScript SDK - the production deployment files - the guide for adding new activity families - an independent builder's package for the second product When its subscription quota ran out mid-hackathon, we kept using it through the Meta Model API directly. Its commits are co-authored and every change was reviewed before merge. Every model call is traced (model, tier, latency, tokens, outcome) and shown to builders in a console, next to a comparison of adaptive and fixed routes.

Team