Skip to content
Adrian Zaschka
All work

Case study · Public AI Hackathon 2.0, Vienna

ida Lotse

A prototype that turns the AI chat on oesterreich.gv.at into a personal assistant. Built in two days by a team of five at the Public AI Hackathon 2.0 (StartUp Edition) of the Federal Chancellery and Digital Austria. I worked on the backend.

Backend developer in a team of five
Role
Public AI Hackathon 2.0 5–6 October 2026, AI Factory Austria, Vienna
Timeline
Django, Vue, Tailwind CSS, Docker, vLLM, Gemma 4
Stack
Prototype Invited to pitch at "Inside the AI"
Result
ida Lotse chat after a move from Graz to Vienna: the two answers as a summary, then a two-step plan to register the new address before a deadline and to inform the bank, employer and insurance, with oesterreich.gv.at as the source, followed by an offer to sign in with ID Austria
Scripted demo mode

The challenge

Challenge 1 of the hackathon asked for an AI-supported digital assistant for citizens. oesterreich.gv.at already has an AI chat that gives information. Our idea was to make it personal and move it from information to concrete help: the next steps for your situation, the calculations that apply to you and forms that are already filled in.

ida Lotse is a hackathon prototype. It shows the idea end to end, but parts of it are simulated, and they are marked as such below.

The demo

The scripted flow from our pitch, with a fictional persona: someone who moved from Graz to Vienna answers two questions, gets a plan, signs in through a simulated ID Austria login, reviews a prefilled registration form and follows its simulated status. 66 seconds, no sound.

My role

I worked on the backend. The assistant is an agent that calls tools, and I built the tools the Django backend provides: the two official calculators, the crawler and search over oesterreich.gv.at, and the structured reply blocks, including the step-by-step plans. I also built the simulated ID Austria login with profile data and wrote the shared API contract between frontend and backend.

What I built

  • Official calculators as tools

    The agent calls the BMF commuter calculator (Pendlerrechner) and the gross-net calculator live instead of reimplementing them. The commuter lookup resolves the address, opens a session and calculates the trip. Ambiguous addresses come back to the user as a question.

  • oesterreich.gv.at index

    A crawler that respects robots.txt, waits at least a second between requests and can resume. It collected 4,990 pages, split into 5,165 chunks with a BM25 search that returns source links. The content is licensed CC BY 4.0.

  • Step-by-step plans

    A plan tool renders each step with why it matters, where to go, the deadline, what to bring and a source.

  • Structured replies

    Questions, calculator results, sources and the login offer arrive as typed blocks, streamed to the browser with server-sent events.

  • Simulated ID Austria & profile data

    A mock login with three fictional personas. The model asks for single profile fields and only gets those, and the interface lists which data was used.

  • Contract first

    One shared contract for events, blocks and TypeScript types, so frontend and backend could be built in parallel.

Built by the team

  • Agent server & law search

    RAG over the Austrian legal information system (RIS) and official forms, with a vector database and Qwen embedding and reranker models. Every request runs in a fresh, isolated container. Forms are prefilled through normalized field keys, so values can be reused across forms.

  • Open-weight inference

    Gemma 4 (26B-A4B) served with vLLM on two A100 GPUs of the EuroHPC supercomputer Leonardo, reached through an SSH tunnel.

  • Chat frontend

    The Vue and Tailwind interface, voice input through the Web Speech API and the multi-step form view.

Architecture

Architecture of ida Lotse The Vue client sends chat messages to the Django backend and receives the reply as server-sent events. For each message, Django calls the agent server, which runs every request in a fresh container with RAG over the RIS and forms, and uses Gemma 4 served with vLLM on the EuroHPC supercomputer Leonardo. When the agent needs a tool, Django runs it: the official BMF calculators, the search index over oesterreich.gv.at, or profile data. Django stores chats and forms in PostgreSQL. REST · SSEchat · tool resultsinferencelive APIsearchVue clientAgent serverGemma 4 · vLLMDjango backendBMF calculatorsoesterreich.gv.atPostgreSQLchat, voice inputfresh container per requestRIS RAG · vector DB · QwenLeonardo (EuroHPC)2× A100agent tools, REST APIstreams reply blockscommuter · gross-netBM25 index, 4,990 pageschats, forms
The Vue client talks to Django. For each message, Django calls the agent server, which runs Gemma 4 on Leonardo and calls back into Django for the calculators, the oesterreich.gv.at index and profile data.

Engineering decisions

  • Live calculators, not copies

    Results match the official calculators because they come from them. The trade-off: the endpoints are undocumented and can change.

  • Tools run where the data is

    The remote agent requests a tool, Django runs it and posts the result back. Calculator calls and profile data stay in the backend.

  • Sources only from search results

    Plan steps may only link pages the search actually returned, or an official homepage. The model cannot invent a link.

  • Data minimization

    The model asks for single profile fields instead of getting the whole profile. The interface shows which fields were used.

  • Ask instead of guess

    Missing or ambiguous details, such as an address with several matches, turn into a question block instead of an assumption.

  • Contract before code

    Events and block types were defined before the first endpoint, so both sides could build against the same shape.

Results

Positive feedback
Very positive feedback from the State Secretary and the product owners.
Invited to pitch
Invited to pitch the project at the AI Austria meetup "Inside the AI".
From question to plan
A plain question ends as a sourced plan with calculations and a prefilled form.

What's next

The ID Austria login is simulated, and forwarding forms to the authorities is not built yet. The next steps would be a real ID Austria connection, the hand-off to the authorities, an encrypted data vault in the browser, and working plain-language and read-aloud modes.

  • ida Lotse reply to a move from Graz to Vienna: two short yes-or-no questions, whether the new address is the main residence and whether a car is registered in Austria, with yes and no selected and a continue button
    Scripted demo mode · Two questions before the plan
  • ida Lotse offers to fill in the form and asks whether it may read name, date of birth and current address from the central register of residents, once and only for this form, with the options to allow it or to type the data in
    Scripted demo mode · Asks before it reads register data
  • Prefilled registration form for review: name, date of birth and current address of a fictional persona from the register, the new Vienna address and the move-in date taken from the conversation and flagged for checking, the main-residence question and a button to sign with ID Austria
    Scripted demo mode · Prefilled form, fictional persona
  • Confirmation card: the new address is registered, with a reference number, a note that the confirmation is in the digital mailbox and a three-stage progress bar: sent, under review at the registration office, confirmed
    Scripted demo mode · Simulated hand-off to the authority