Notes from AI Gothenburg
This week I went to AI Gothenburg, a networking event for people building with AI in the city. I mostly went to meet one person, and that conversation turned out to be the best part of the evening. I left with three ideas I keep coming back to.
Most of my work runs on frontier models. I'm building an LLM-driven simulation at the University of Gothenburg, and most of my code starts in Claude Code. That costs money every month, and the bill grows with how much I use it. So the first thing that caught my attention was a setup that doesn't send everything to the biggest model.
Frontier plans, local works
The setup I saw splits the work in two. A frontier model does the planning and orchestration: it breaks a task down, decides what should happen in which order, and checks the results. The actual work goes to a local model. Not a small one, but a large open-weight model like Qwen, GLM or Kimi, running on hardware you control.
It makes sense when you look at where the tokens go. Planning is a small share of them, and it's where a frontier model earns its price. Most tokens are spent doing the work: reading files, writing code, summarising, and filling in the steps of a plan that's already been made. Moving that part to a local model is how the subscription costs come down.
It changed how I think about choosing models. The question isn't which model is best. It's which model is good enough for each step.
The split matters beyond cost, too. Organisations that handle sensitive data, like universities, have good reasons to run open-weight models on infrastructure they control. Frontier models can then be kept for the parts that really need them.
Context graphs
The second idea was about memory. Most agents I use remember things as text: a long system prompt, a file of notes, past conversations put back into the context window. That works until the context fills up, and the model has to find the relevant part on its own.
A context graph stores what an agent knows as entities and the relationships between them: people, projects, decisions, and what depends on what. When a request comes in, the agent pulls the part of the graph that matters instead of everything it has ever seen. I got to see a personal agent built around one, and it made the idea concrete for me.
It connects to something I already do. My repositories have a CONTEXT.md glossary that tells agents what our words mean. A graph is the same instinct taken further: give the model structure, not just more text.
Tutors that learn from students
The idea I've thought about most since is what this could mean for learning. A digital tutor for university students is easy to imagine and hard to make good. Most attempts start from the course material: load the textbook, then answer questions about it.
The more interesting data is how students actually use the tutor: which questions they ask, where they get stuck, what they misunderstand, and what finally makes something click. Collect that, and you could build a context graph of how a subject is learned, not just what it contains. A tutor grounded in that graph, and maybe eventually fine-tuned on it, could meet each student where they are instead of where the syllabus says they should be. That data is personal, so it would have to be handled with care. Running open-weight models on infrastructure the university controls would be one way to keep it there.
I see a small version of this in my own work. In the simulation I'm building, law students only find the key facts by asking the right character the right question. I've started wondering what those questions would show if we looked at them as data.
What I'll try
Two things I want to test on my own setup:
- Keep the grill, spec and ticket steps of my workflow on a frontier model, hand the implement step to a large open-weight model, and log where it falls short.
- Build a context graph of Dispatch (opens in a new tab) from what my workflow already produces: decision records, specs, tickets and the commits that close them. Then ask an agent why the code works the way it does, and compare its answers with and without the graph.
I went for one conversation and came home with three ideas. That's a good trade for an evening.