Acorn

The landing page.
Julia's September: move-in, auditions, club meetings, and the start of classes. Todos are labeled by who added them, her or her agent.
The week view. Her agent picked these sections around ballet rehearsals and her Friday work-study shift.
The academics page: the autumn plan, her AP credit, and search over the full catalog.
A course's real sections, each lecture paired with a discussion. Times can be corrected by her or her agent.
Her clubs, with meeting times that show up on the calendar.
The scratchpad: her quick notes and the goal her agent structured into milestones.
The activity log. Each entry shows whether she or her agent made the change.

Every time I switched between building something technical and researching what I need to do to prepare for freshman year at Stanford, while using the same frontier models at my disposal, I was hit in the face with a sharp divergence in performance. The same model that built an entire secure backend meant to withstand ten thousand users and connected it to a frontend without trouble (the CORS errors alone took me hours just 3 years ago), was reduced to a useless machine awkwardly misclicking around Stanford Axess trying to retrieve any piece of information at all. It searched from stale sources and did not know what to do with broken links. It misclicked and accidentally closed browsing sessions. It forgot everything about me in a matter of a few messages. I saw that consumer AI was nowhere near the frontier I knew in development, and the problem was context and browsing.

Which is why, when I heard that WebMCP, a concept I had heard of but never seen working, was actually moving forward, I was thrilled. This hackathon came at the right time, and with it the idea to finally streamline the process I had been struggling with all summer: pointing frontier intelligence at possibly the most important planning task of my adult life. I named it Acorn, an homage to the infamous Stanford squirrels that were darting around during my visit.

Acorn is as much a context layer as it is a website. When we build with agents, we use markdown files in the repo so the model can carry goals, constraints, and decisions from one session to the next. Acorn acts as that durable context window, a version of which the average person could meaningfully interact with. You can talk to your agent and have it write things down, or scratch a half-formed idea into the pad yourself and have your agent make sense of it later. Either way you are both working on the same workspace: your goals, your notes on frosh-friendly classes, and the professors who you think might give you a research opportunity -- all forming a plan built collaboratively.

The page registers 22 tools with the browser using WebMCP, giving an agent human-level control over the workspace. Everything a student would otherwise keep in their head has a place: a calendar that shows your actual week, a plan for each quarter, the clubs you joined with their meetings, the credit you brought in from AP or IB, and a scratchpad for any other tidbits of information. The official Stanford catalog with 15,618 courses across 256 departments is included in the workspace. So when you ask your agent for a schedule, it makes use of the actual options: it remembers the hours you blocked off, plans around your club meetings, picks lecture times that fit your week, and puts the result on your calendar.

The biggest question was how much to hardcode and how much to leave to the user's agent. An empty catalog is useless, but a catalog nobody can correct goes stale when anything changes. I ended up shipping verified reference data as the base and allowing edits on top of it. The student or the agent can amend (or add) any course, club, or activity.

To test all of this, I spun up Fable agents that played the students, each of them using the agentic workflow of Codex to plan their quarters collaboratively. Those rounds, and then planning my own autumn in the app, caught a number of problems. For a while the catalog had every lecture at Stanford and not a single discussion section, because my importer failed to scrape them. The same goal once appeared twice on the scratchpad, one copy with a milestone checklist and one without, because onboarding and the agent each saved it their own way. Saves took 32 seconds at one point, because every save was carrying ten full copies of the workspace as undo history, so I capped the history and saves dropped to three seconds. And once the app said a change was saved when it never reached the server, so saves now confirm against the server with an idempotency key.

Through this, I learned that the divergence I kept running into had nothing to do with model capability. Once the browsing was replaced with webMCP tools and the context was durable, the same model that built my backend planned my quarter just as well.

Next, I want to ship a barebones version of the workspace, giving a user's agent more autonomy over it, allowing it to research any university and build its catalog, programs, and clubs from official sources, so Acorn can extend beyond Stanford to any college, and past college to any long-running task where a person and their agent need one shared memory. The squirrels I named this after bury acorns all over campus and find them again months later, and that is what I want from planning with an agent: whatever the two of you put down, you come back and it is still there.