Builders & Brews Stockholm: The Hard Questions Arrive Earlier
Stockholm, Sweden | September 18, 2026 | Netlight
Insights by Stockholm MLOps
“If you're going home from work, you don't have the whole Google Maps in your head.”
Physical AI builder
A robotics student at Builders & Brews Stockholm was trying to solve a very practical problem.
His robot needed to move a screwdriver from a table to a toolbox. The environment contained far more information than the task required. Instead of sending the entire representation of the room into the reasoning system, he first asked a simpler question:
Which objects actually matter right now?
By filtering the environment before reasoning, he reported reducing tokenization by roughly 60 to 63 percent.
It was one of ten projects built and demonstrated during the Stockholm stop of Builders & Brews, a global builder series from Nebius and Tavily. The Stockholm edition was hosted with Stockholm MLOps at Netlight, with Lovable participating and the wider global hackathon run in partnership with NVIDIA. The official tour spans 20 cities.
But the robot was only one signal from the day.
A student moved an impractical local workload to cloud infrastructure in minutes. A company knowledge system tried to make an entire organization navigable without feeding everything into one request. Two autonomous agents negotiated while the judges asked what they should actually be allowed to promise. A medicine assistant discovered that producing the answer was not enough. The user also needed the official source behind it. A scientific application could produce a convincing interface long before the science underneath had been validated.
Across the projects, something interesting happened.
The builders could get far enough, fast enough, that the difficult questions arrived while they were still in the room.
That may be the most important signal from Builders & Brews Stockholm.
Not that AI can create applications quickly.
We already know that.
The more interesting question is what happens next.
Summary: Key Insights From the Hackathon
The difficult questions increasingly arrive after something already works. Builders reached functioning prototypes quickly enough that questions about trust, product value, architecture, scientific validity and authority surfaced during the same day.
Several of the strongest projects became better by reducing information rather than adding more capability. The Physical AI project reduced the robot's world. Company Brain navigated only relevant organizational knowledge. Hollow Tree constrained retrieval to approved healthcare sources.
Current information and trustworthy information are different engineering problems. Search can retrieve the latest answer. High stakes applications still need provenance, authoritative sources and a way for users to inspect the evidence.
Autonomous agents become much harder when they can make commitments. OnBehalf could demonstrate agent to agent negotiation. The harder question was how to encode the human or company's actual mandate.
Infrastructure remains real, but the barrier to using it is falling. Builders could move between local and cloud execution, call model infrastructure through APIs and access search, application generation and accelerated computing without building every layer themselves.
Rapid application creation does not collapse validation at the same speed. A scientific interface can be built quickly. Scientific correctness still has to be established. A healthcare application can be prototyped quickly. Safety still has to be designed.
The judges repeatedly returned to one deceptively simple question: what is this actually for? Even in a deeply technical room, clear problem definition remained one of the strongest differentiators.
What This Event Was Really About
Builders & Brews was set up as a build day rather than a conventional Stockholm MLOps evening event.
Nebius and Tavily brought a global hackathon format to Stockholm. Lovable joined as a partner. NVIDIA was part of the wider hackathon. Builders received access to infrastructure, search, application development tooling, technical support and time to experiment. Netlight was the Stockholm venue
That matters because it created a different kind of evidence.
A presentation tells us what a technology is intended to do.
A hackathon shows what happens when somebody actually tries to use it.
And the ten projects were remarkably varied.
There was sensitive health information, mental performance, molecular simulation, fact checking, reusable AI workflows, robotics, enterprise knowledge, autonomous commercial negotiation, medicine regulations and Swedish taxation.
This was not ten variations of the same chatbot.
The projects reached into healthcare, finance, science, enterprise workflows and physical systems.
What connected them was not one architecture.
It was the speed with which builders could move from an idea into something concrete enough to expose the next problem.
That next problem was different for every team.
For the robotics student, it was computational efficiency.
For Company Brain, it was information architecture.
For OnBehalf, it was authority.
For the medicine application, it was provenance.
For the tax assistant, it was discovering the questions a user does not know to ask.
For the molecular simulation project, it was the uncomfortable but essential distinction between a working interface and valid science.
The hackathon therefore produced a useful snapshot of modern AI development.
Implementation is accelerating, but the rest of product development has not disappeared with it.
In some cases, acceleration makes those other problems visible sooner.
A Modern AI Development Environment Walked Into a Hackathon
The partner companies matter to this story because they represented very different things a builder could now access during the same day.
Nebius brought the infrastructure layer. Anton Smith's presentation moved from networking, storage and NVIDIA GPUs through Kubernetes, Slurm, Ray and SkyPilot into higher level services for development, jobs and inference.
That picture matches Nebius' current product direction. Token Factory provides production inference across open and custom models, while its Serverless AI offering separates finite workloads into Jobs and real time services into Endpoints. Nebius is also building Physical AI Workbench around composable simulation, training and deployment workflows.
Tavily represented a very different layer.
Evan Rimer's presentation was not about giving a human ten blue links. It was about converting the live web into usable information for another machine.
Tavily currently describes itself as a web access layer for AI agents, spanning Search, Extract, Research, Crawl and Map. Its search product emphasizes fresh, reranked context, and its own extraction guidance recommends selecting relevant sources before extracting their content rather than indiscriminately retrieving everything.
Lovable attacked the application development layer.
Diana Heislere showed an environment where a builder can reason about a product before implementation, then move into application creation. Lovable's current Plan mode is explicitly designed to work through requirements and features before code is written, while its platform now also includes automated browser and application testing, connectors and integrated security scanning.
And Hugi Aegisberg deliberately broadened NVIDIA beyond the familiar GPU story.
That is consistent with the size of NVIDIA's current software ecosystem. CUDA and CUDA X span accelerated computing and optimized libraries, while Omniverse, Cosmos and related tooling now extend into simulation and Physical AI.
The interesting part was not that these four companies could be drawn as a neat stack.
They cannot.
Builders did not use every technology from every company, and we should not pretend they did.
The interesting part was that a single room could provide access to serious compute, current web information, rapid software creation and a large accelerated computing ecosystem.
That changed what could reasonably be attempted in a day.
1. The Difficult Questions Arrived Earlier Than Expected
One of the clearest patterns across the showcase was that several teams already had something working when the most important question appeared.
Oliver had created his workflow system.
The judges still wanted to know what someone would repeatedly use it for.
The answer became much clearer when he stopped describing the abstraction and said:
“Say you're an enterprise, you could design a flow for onboarding someone.”
Oliver
Suddenly the product was concrete.
The molecular simulation project reached a similar boundary.
Using Lovable, the builder had created a browser based experience around the idea of collaborative molecular simulation.
The interface existed.
The scientific results did not.
They were placeholders.
That is not a criticism of the project. It is exactly what made the demo interesting.
Application velocity and scientific validity had become visibly separate timelines.
The medicine application had another version of the same experience.
It could determine that someone travelling with a particular medicine might need documentation.
The panel then asked for something extremely simple:
“It could be helpful putting the URL of the website where it actually says that.”
Panel feedback
The prototype had reached the point where the next problem was no longer generating the answer.
It was proving the answer.
That happened repeatedly throughout the day.
Faster building did not eliminate hard product questions.
It allowed teams to reach them sooner.
2. The Robot Did Not Need the Whole World
The Physical AI project produced one of the strongest technical insights of the day.
“Often it just sends the whole object to reason, the whole map to reason.”
Physical AI builder
That is an easy architecture to understand.
The robot has a representation of its surroundings.
Give all of it to the reasoning system.
But the builder noticed how wasteful that could become.
“Usually that consumes a lot of tokens, so we don't really want to do that.”
Instead, the system first determined which objects mattered to the current task.
“We use this little map to identify which objects are the relevant ones and just only use that for our navigation.”
The builder reported that this reduced tokenization by approximately 60 to 63 percent.
The exact result belongs to one hackathon project, not a general benchmark.
But the principle appeared elsewhere.
Company Brain had an entire organization's knowledge available to it. The team did not want to inject that entire body of information every time somebody asked a question.
It built a graph so the system could navigate toward the relevant knowledge.
“It doesn't have to upload all the knowledge, but only the ones that you actually need.”
Company Brain team
Hollow Tree went even further.
The objective was not only relevance.
It was acceptable relevance.
The health companion constrained its retrieval to a selected set of healthcare information sources.
Different projects had independently reached a similar architectural conclusion:
Having more information available does not mean every piece of information belongs in the current decision.
That is a much more useful insight than simply saying context matters.
The engineering problem is increasingly one of selection.
3. Search for an Agent Is Not Search for a Human
Tavily's presentation gave useful language to another problem visible in the projects.
When a human searches the web, the output can be a page of results.
The human scans titles, opens pages, judges relevance and reads.
An automated system needs something different.
It needs the web turned into usable evidence.
Evan described a pipeline that moved from the query to relevant URLs, retrieval, extraction, chunking and ranking before the relevant information returned to the application.
That distinction became tangible in the projects.
A traveller asking whether a medicine requires documentation does not merely need pages mentioning the medication.
The system needs the applicable rule for the particular route.
A fact checking extension does not need the entire internet.
It needs relevant evidence for a particular highlighted statement.
Hollow Tree does not want the most popular result for a sensitive health question.
It wants relevant information from sources the product has decided to trust.
This distinction matters because search becomes part of application behavior.
When the underlying information changes, the application's behavior can change with it.
And once that happens, retrieval quality is no longer an accessory feature.
It becomes part of the reliability of the system.
4. In High Stakes AI, the Source Becomes Part of the Product
The medicine travel project exposed another layer of the same problem.
The builder understood that regulations change.
“For us, it's important to get updated regularly regarding the regulation.”
Medicine travel builder
But fresh information and trusted information are not the same thing.
A person standing at an airport with controlled medication needs more than a confident generated answer.
They need to know where the requirement came from.
Julia's Swedish tax assistant had already incorporated a similar idea.
The application did not merely explain whether an expense might be deductible.
It also showed:
“And where the information came from.”
Julia
Hollow Tree surfaced sources.
The fact checking browser extension was fundamentally built around evidence.
Across these projects, verification was becoming visible in the product itself.
That is important.
Traditional software often hides its validation mechanisms.
AI applications may increasingly need to expose them.
The source link, citation, approved source set or supporting document becomes part of the user experience because the user may need to inspect, challenge or act on the result.
In consequential AI, trust cannot always remain behind the interface.
Sometimes it has to be rendered on the screen.
5. Agents Become More Complicated When They Can Say Yes
OnBehalf had one of the more ambitious propositions of the day.
Prince wanted agents to negotiate with other agents.
“We want them to carry out autonomous actions for us.”
Prince, OnBehalf
The seller creates an agent, defines commercial boundaries and allows it to negotiate with a buyer's agent.
“I create my agent, add my mandate, add the exact price that I want, and let it free.”
The word mandate is where the project becomes much more interesting.
Price can be bounded relatively cleanly.
A real enterprise relationship includes far more.
Support obligations.
Quality commitments.
Service levels.
Delivery conditions.
Exceptions.
Strategic relationships.
That is exactly where the panel pushed.
“There are a lot of qualitative factors that you cannot really put as a quantitative thing that comes into negotiation.”
Panel feedback
Prince argued that this was where language models could participate dynamically rather than relying on a static pricing rule.
Perhaps.
But the deeper production question survives regardless of the underlying implementation.
How does a human express what an autonomous system is actually allowed to agree to?
That is not only an AI problem.
It is a representation problem, a governance problem and ultimately a business problem.
Agents get much more interesting when they act.
They also become much harder.
6. Infrastructure Became Something Builders Could Switch Into
Oliver supplied the day's most human infrastructure benchmark.
He wanted to use local models partly because he was a student.
“I tried to download, like, local LLM models because as a student, I don't want to spend my money on AI subscriptions. I'd rather spend it on beer and going out with friends and stuff.”
Then he tried a difficult workload.
“My computer was, well, boiling, basically.”
Rather than spending the remainder of the hackathon tuning his laptop, he changed architecture.
He connected the workflow to Nebius and moved execution away from the local machine.
His reported result was dramatically faster and extremely inexpensive for the specific request.
That should not be treated as an independent benchmark.
The more interesting observation is how easy the architectural change had become.
A developer could begin locally, encounter a real compute limit and then move the workload elsewhere without turning the entire hackathon into an infrastructure project.
Nebius' current Serverless AI direction reflects exactly that type of abstraction. Jobs run finite containerized GPU workloads and release the resources when completed, while Token Factory provides API access to hosted inference over a range of open models.
Infrastructure has not disappeared.
Anton's presentation made that extremely clear.
The GPUs, storage, networking, orchestration and scheduling systems are still there.
What is changing is how much of that machinery an individual builder has to operate directly before testing an idea.
7. Building the Interface Was Often the Easy Part
Lovable made one of the other big changes visible.
Software can now become tangible extremely quickly.
The molecular simulation project is the cleanest example because the contrast was impossible to miss.
A complex scientific concept had a usable application surface.
But the simulation behind the application was still placeholder output.
The interface looked further along than the science.
That is an important distinction as AI generated development becomes more powerful.
Lovable itself has moved beyond simple page generation. Its current product includes planning before implementation, automated application testing, connected external systems and integrated security tooling.
But no development environment can automatically supply missing domain truth.
It cannot determine whether a molecular simulation is scientifically valid merely because the user interface works.
It cannot decide what Swedish tax guidance is legally correct without the right source material.
It cannot define the commercial limits of an autonomous negotiation agent.
This suggests an important shift in what becomes scarce.
As the cost of producing the software surface falls, domain knowledge, validation and judgment become relatively more visible.
The application can arrive sooner than confidence in the application.
8. The Judges Kept Asking the Same Nontechnical Question
Before building began, teams were advised that the first seconds of the final pitch mattered.
By the showcase, it was obvious why.
Again and again, the judges asked builders to make the problem concrete.
What would somebody use this for?
Why does dynamic molecular simulation matter?
Why a knowledge graph?
How does a real enterprise negotiation handle nonprice commitments?
Where is the authoritative source?
What does this help me do tomorrow?
This is easy to dismiss as presentation advice.
It was more important than that.
Several teams were technically capable of building something before they had fully resolved the product's clearest everyday meaning.
That situation is likely to become more common as implementation accelerates.
In traditional software development, technical difficulty can delay a weak idea for months before anyone sees it.
Modern AI tooling can produce enough software to expose the weakness in the idea almost immediately.
That may be healthy.
A bad assumption now has fewer places to hide.
What the Ten Projects Tell Us
Ten projects are far too few to claim anything about the entire AI industry.
But they are enough to tell us something about this particular room.
Five of the ten projects were primarily aimed at individual users: Hollow Tree, Mental Gym, the fact checking extension, the medicine travel assistant and the Swedish tax assistant.
Two were strongly enterprise or commercial: Company Brain and OnBehalf.
Three focused on developers, science or robotics: the workflow builder, collaborative molecular simulation and Physical AI navigation.
At least five depended materially on retrieval or external knowledge.
At least four placed AI inside a more active workflow rather than using it simply as a conversational assistant.
Several dealt with consequential domains such as health, taxation, regulation and commercial commitments.
What is striking is the diversity.
The builders were not all chasing the same agent pattern.
They were not all building search.
They were not all using the same development tools.
The commonality was simply that sophisticated AI capabilities had become accessible enough for people to apply them to very specific problems.
The creative energy was moving toward the problem domain.
Only Said Here: What Builders Learn by Actually Building
Some of the best intelligence from a hackathon lives in small moments.
A student's laptop physically became the wrong architecture.
A robotics student discovered that a better optimization was to show the system less of the world.
A technically sophisticated workflow product became easier to understand the moment its creator said “employee onboarding.”
A scientific product looked convincing before its underlying science was ready.
A privacy focused health application included a button that instantly disguised itself as a weather app if someone entered the room.
A company knowledge team had to defend why a knowledge graph was actually the right architecture rather than simply using the phrase because it sounded sophisticated.
An autonomous negotiation product became substantially more complicated the moment the judges introduced customer success and qualitative commitments.
A medicine application discovered that one of the most important missing features was not another AI capability.
It was a hyperlink.
And a tax assistant was pushed toward a harder problem than answering questions:
helping people discover the questions they do not know they should ask.
Those are not conclusions from a keynote.
They are what happens when ideas collide with implementation.
Signals From the Room
The judges' questions may ultimately be as interesting as the applications.
The room was not spending much time debating whether generative AI was useful.
That question had effectively moved on.
Instead, people challenged architecture.
Why a graph?
They challenged authority.
What can the agent actually promise?
They challenged trust.
Where did this information come from?
And they challenged product value.
Who is going to use this?
That tells us something about where a technically sophisticated builder community is placing its attention.
The conversation has become less abstract.
The unit of discussion is increasingly the system somebody is actually trying to build.
That is exactly where Stockholm MLOps wants the conversation to be.
What Builders & Brews Stockholm Signals
The temptation after a hackathon is to write about speed.
Look how much people built in a day.
That was visible here, but it was not the most interesting thing.
The important part was what the speed exposed.
When a team can assemble an interface quickly, it has to confront whether the underlying product is valid.
When current web information can be retrieved quickly, the team has to confront which sources deserve trust.
When an autonomous agent can negotiate, someone has to define what it is authorized to agree to.
When a powerful reasoning system can inspect a robot's entire environment, an engineer has to decide whether it should.
When serious compute can be reached through an API, the architectural question moves from “Can I access this?” toward “Where should this workload actually run?”
This does not mean the technical problems are solved.
The Physical AI project proved the opposite.
Infrastructure still matters.
Models still matter.
Search still matters.
Engineering still matters.
But the boundary is moving.
Builders are reaching the next problem earlier.
That may be one of the most consequential effects of the current generation of AI tooling.
The distance between an idea and a testable implementation is shrinking.
The distance between a testable implementation and a trustworthy, useful, correct product is not shrinking at the same rate.
Builders & Brews Stockholm made that gap visible in a single day.
And that is precisely why hackathons can now tell us something important about AI in production.
They are no longer only showing us what people can build.
They are showing us where the hard problems appear once they do.
Speakers and Companies Featured
Anton Smith, Nebius
Director of Product Management, Cloud Native AI Services. Anton presented the infrastructure available beneath modern AI development, from compute and orchestration to serverless workloads and model serving.
Evan Rimer, Tavily
Forward Deployed Engineer. Evan focused on turning the live web into information an AI system can retrieve, extract and reason over rather than simply presenting conventional search results.
Diana Heislere, Lovable
Customer Success. Diana demonstrated how product requirements, planning and application creation are increasingly being brought into one AI assisted development environment.
Hugi Aegisberg, NVIDIA
Regional Developer Relations Manager, Nordics. Hugi introduced builders to the broader NVIDIA developer ecosystem across accelerated computing, software and Physical AI.
Patrick Couch, Stockholm MLOps
Patrick opened the event and connected the global hackathon to Stockholm's local AI in production community.
The Stockholm edition was hosted at Netlight as part of the global Builders & Brews Hack Edition. The global hackathon included four tracks, Coding & Agentic Engineering, Best Apps & Agents, Personal AI and Physical AI, with NVIDIA hardware awards, Tavily awards and local city prizes among the published competition categories.
Related Insights
Stockholm MLOps #38: The Agent Era Is Becoming an Infrastructure Era
The Fall Bash explored what happens when agents become operational actors. Builders & Brews adds hands on evidence from systems that negotiate, retrieve, execute and interact with the physical world.
Read Stockholm MLOps #38
Stockholm MLOps #34: Designing, Embedding & Orchestrating Physical AI
The Physical AI hackathon project provides a practical continuation of #34's discussion around compute constraints, robotics and real world AI systems.
Read Stockholm MLOps #34
Stockholm MLOps #32: Guardrailing Vibe Coding
Lovable and the day's rapid application building connect directly to the earlier discussion about what changes when AI can generate increasingly large parts of software development.
Read Stockholm MLOps #32
Event Details
Event: Builders & Brews: Hack Edition
Date: September 18, 2026
Location: Netlight, Stockholm
Hosted with: Stockholm MLOps, Nebius, Tavily, Lovable, NVIDIA and Netlight
Format: Workshops, technical support, build sessions and ten recorded project showcases
Global program: Builders & Brews Hack Edition, 20 city tour