BR-Budget.
Software dla agenta,
który zarządza moimi finansami.

Nazywam to agentic-first. Jeśli agent może pobrać dane, zrozumieć je i wrócić z decyzją, człowiek nie musi po nie klikać. UI zostaje do kontroli i korekt.

Mamy precedens. Mobile-first dwadzieścia lat temu też brzmiał prowokacyjnie. Najpierw projektowano na desktop, mobile był dodatkiem. Mobile-first odwrócił logikę.

Agentic-first to podobna zmiana, tylko głębiej w produkcie. Projektuję dane, reguły, uprawnienia i historię decyzji tak, żeby agent mógł na nich naprawdę pracować.

Człowiek mówi do agenta: „sprawdź, czy stać mnie na nową kosiarkę”. Agent łączy się z API, pobiera saldo, kategoryzuje wydatki, sprawdza zobowiązania i podaje odpowiedź. Człowiek nigdy nie otwiera dashboardu.

LLM nie wie, gdzie chodzę do knajpy, jakie mam subskrypcje i jak rozliczam VAT. To są dane i reguły żyjące w aplikacji. Aplikacja musi być czytelna dla agenta.

Brzmi prowokacyjnie. Mogę się mylić. Dlatego postanowiłem to sprawdzić w praktyce.

Dlaczego akurat budżet.

Od lat używałem YNAB. Płaciłem. Myśl „po co płacić za coś, co umiem zbudować sam” rosła. Mniej niż rok temu próbowałem zbudować Solon, startup finansów personalnych. Wtedy projekt rozbił się o realne koszty developmentu.

Dziś, w 2026, ten sam projekt postawiłem od zera do produkcji w kilka dni. Taka różnica zmienia kalkulację dla foundera i CTO budującego narzędzia wewnętrzne.

Architektoniczna decyzja, która zmieniła wszystko.

„Po co buduję zaawansowane filtry i raporty, skoro za chwilę agent będzie mi je generował na żądanie?”

Zacząłem klasycznie, UI-first. Ekrany, transakcje, kategorie, raporty. W trakcie zatrzymałem się i przerzuciłem priorytet. API-first. Agentic-first.

• REST API i MCP do odczytu danych oraz wybranych operacji
• Klucze API per użytkownik, podpinane pod Claude Desktop, ChatGPT i Hermes
• Klucz agenta ograniczony do danych użytkownika i nadanych uprawnień
• UI zostaje do kontroli, korekt i budowania zaufania

Co dziś robi BR Budget.

Chcę wiedzieć, ile mogę wydać, co już zaplanowałem i ile rzeczywiście odłożyłem.

Kontrola wydatków łączy import transakcji, budżety z regułami i planowane zakupy. Najpierw sobie pomaga odłożyć część wpływów, a Pauza daje czas na zastanowienie przed większym zakupem. Agent ma dostęp przez API i MCP, zgodnie z uprawnieniami swojego klucza.

Wnętrze, decyzje, które się liczą.

„Eksperyment, który traktuję jak system produkcyjny.”

Kwoty są trzymane w groszach. Transfer ma wspólny transferId i role outflow/inflow. Bootstrap ładuje snapshot, settings i import coverage jednym requestem. Agent API działa w osobnym scope autoryzacji.

Tempo otwiera nowe pytania.

„AI w pętli developerskiej zmienia tempo budowania o rząd wielkości. Liczy się to, co z tym tempem robisz.”

MVP powstał szybciej, niż jeszcze rok temu byłoby to możliwe. Najciekawsze pytanie brzmi: które rzeczy nagle opłaca się sprawdzić, skoro prototyp z prawdziwą domeną można doprowadzić do produkcji w kilka dni?

Pierwsza wersja miała punkty, streaki i nagrody za trzymanie budżetu. Wyciąłem to po pierwszych tygodniach. Nie działało.

Zastąpiłem to modułem Pauza. Większy wydatek? Wpisujesz rzecz, kwotę, link do sklepu i odpowiedź na pytanie kontrolne. System wylicza czas blokady decyzji proporcjonalnie do kwoty.

Ta przerwa daje mi szansę wrócić do zakupu, kiedy pierwszy impuls już minie.

Działa już także Najpierw sobie: wykrywanie przychodów, propozycja oszczędności, słoiki i rozliczanie przelewów. Postęp opiera się na pieniądzach rzeczywiście odłożonych, a osiągnięty cel dostaje trofeum.

Agent może już analizować dane i zarządzać planami przez MCP. Dalej sprawdzam, kiedy system powinien sam wysłać mu sygnał o zdarzeniu.

Wpłynął przychód. Odnowiła się subskrypcja. Kategoria przekroczyła limit. Pojawił się wydatek, który wygląda jak impuls.

Wtedy aplikacja sama odzywa się do mnie, kiedy ma powód.