Skip to content
Borut Balazek

AI Engineering

Language-model systems I built for clients and my own products, with how the data moves through each one and why I built it that way. The workflow I use to build with coding agents follows.

Systems I've built

Four systems built around language models, two for client work and two of my own products. Each shows how the data moves and the decisions behind it.

MarketAlerts · founding engineer · client work

Classifying financial signals

I owned the AI classification layer and alert engine for an investment-intelligence platform. It turned filings and financial news into events users could follow across 20+ markets. The company wound down in March 2026.

How the data moves
  1. Filings, transcripts and news
  2. Airflow pipelines
  3. First cut by a cheap model
  4. Hard cases to a stronger model
  5. Classified events
  6. Alert engine
  • Python
  • Airflow
  • Kubernetes
  • OpenAI
  • Azure OpenAI
  • Gemini
  • Perplexity
  • TypeScript
  • BullMQ
Why I built it this way: Classifying financial signals
  • Classification is hierarchical. A cheap model takes the wide first cut and a stronger one runs only where the decision is hard, and when a result comes out wrong there is a level to inspect instead of one long prompt to stare at.
  • Providers sit behind one registry keyed by name, and each key resolves to that provider's whole config. Azure OpenAI needs an API version and a deployment name that OpenAI does not, so a flat shared interface would either hide that or leak it.
  • Model output gets stripped of markdown fences before parsing. A model asked for JSON wraps it in a code block often enough to break a parser that trusts it.
  • The earnings-call summariser turns raw transcripts into structured highlights. It started on OpenAI and moved to Gemini in production.
  • For users, an analyst chat streams answers backed by live web search through OpenAI and Perplexity, with history shared across devices, voice questions and plan-based usage limits.
MarketAlerts case study →

AI tutoring platform · senior software engineer · client work

Cost control and memory for an AI tutor

I replaced message-based limits with cost-based metering and built background memory for an AI tutor used by millions of secondary-school students. The client is under NDA, so I describe only the engineering problems.

Every tutor request
  1. Student request
  2. Affordability check
  3. Model call
  4. Charge on success
Memory, in the background
  1. Conversation
  2. LLM pulls out lasting facts
  3. Stored memories
  4. Nightly merge and prune
  • TypeScript
  • Next.js
  • tRPC
  • PostgreSQL
  • Drizzle ORM
  • Inngest
  • Stripe
Why I built it this way: Cost control and memory for an AI tutor
  • Usage was counted in messages, which says nothing about cost on a product billed per token. I replaced it with cost-based metering on every plan tier, so the limit the product enforces is what each request costs.
  • The affordability check runs before the model call and the charge only after it succeeds, so a failed request costs the student nothing.
  • Memory runs as a background pipeline on Inngest. An LLM pass extracts lasting facts from conversations, and a nightly pass merges and prunes them, spread across a four-hour window so database load stays flat overnight.
  • Credit top-ups sit alongside subscriptions through Stripe, including bank transfers that settle days after checkout, and the admin side breaks consumption down by user type.

Metis · my own platform

Retrieval over financial news

I built Metis to connect financial news with market prices. It processes around 100,000 articles a day from 5,000+ sources, with separate processors for enrichment and embeddings that support retrieval.

How the data moves
  1. Feeds and archives
  2. Language, entity and sentiment processors
  3. Self-hosted embedding service
  4. Qdrant
  5. Semantic search and agent tools
  • TypeScript
  • NestJS
  • Python
  • FastAPI
  • Rust
  • Qdrant
  • PostgreSQL
  • ClickHouse
  • Meilisearch
  • BullMQ
  • RabbitMQ
  • Anthropic
Why I built it this way: Retrieval over financial news
  • Embeddings go to Qdrant, next to PostgreSQL, ClickHouse and Meilisearch, which all kept their jobs when the vector index arrived.
  • Natural-language search in the client API embeds the query into the same vector space as the stored articles, drops matches under a minimum similarity and puts one deadline on the embed and search calls together.
  • A prediction-market strategy runs as an LLM agent with tools. Before it decides on a market it pulls related news from the last few days by embedding similarity and decides with those articles in its context.
  • Topic tagging and asset matching each have an evaluator that runs candidate thresholds over a sample of real articles and reports what changes, down to precision and recall for the asset matcher.
  • The models for embeddings, entity recognition, sentiment and language detection run as Python and FastAPI services, and clustering runs as a Rust service. LLM summaries go through OpenAI, Anthropic or Ollama.
Metis revisited (blog) → Metis case study →

Guestavo · my own product

An MCP server for running a venue

I built Guestavo for independent hospitality venues. Its MCP server lets an operator manage bookings, menus and other venue work from an AI client, with scoped access and an audit trail for changes. Live in beta.

How the data moves
  1. AI client
  2. MCP server over stdio or HTTP
  3. Key scope and rate limit
  4. Venue data changed
  5. Audit entry with before and after
  • TypeScript
  • MCP
  • Fastify
  • Next.js
  • PostgreSQL
  • Drizzle ORM
  • BullMQ
Why I built it this way: An MCP server for running a venue
  • Every change an agent makes is logged with its before and after state, and it can be undone.
  • API keys are scoped per organisation, property and action, rate-limited, and behind a kill switch.
  • The server speaks both stdio and streamable HTTP, so it works from a desktop AI client as well as a hosted one.
guestavo.com → Guestavo on the projects page →

How I build with agents

I use coding agents on client work and my own products, including Guestavo. The workflow gives each stage a concrete result, keeps project knowledge close to the code and asks a separate agent to challenge the result before delivery.

How a change moves
  1. Spec, phases and tasks in the repo
  2. Agent implements with skills and MCP
  3. Verification with evidence
  4. Review by a separate agent
  5. PR with the proof attached
  • Claude Code
  • Codex
  • MCP
  • TypeScript
  • ESLint
Why I built it this way: How I build with agents
  • Each stage is its own skill with one result: a spec says what the behaviour should be, a phase plan cuts it into milestones, and tasks give each piece an order and an exit that can be observed. They live in the repository as files.
  • Verification has to show the result: test output, a before-and-after, a screenshot for anything visual.
  • A different agent then reviews the change in a fresh context, with the accepted requirements and raw proof but without the author's conversation. It can challenge the result without inheriting the author's reasoning. The proof and findings go into the pull request.
  • The reusable workflow part is public in bobalazek/skills. It covers planning, development and review, with productivity and UI/UX workflows alongside them. The project knowledge and connected tools remain part of the wider setup.
  • MCP servers let agents read and write real project state, such as claiming a task and posting progress in my project manager, instead of guessing at it.
  • The workflow combines deterministic checks with independent agent review and human judgment. Agent mistakes that keep coming back get promoted into lint rules.
  • Human judgment stays part of the review; a passing automated check does not settle every design or product decision.
Use the public skills → How I work with coding agents (blog) → My agent skill tree (blog) →

Open-source agent skills

I kept asking agents to look for the helper that already existed. Then I'd ask them to explain the change and show that it worked. Those requests kept coming back, so I started writing down the workflow.

These skills distill workflows I've used internally for several months into something you can use in your own projects. Each gives an agent a focused job and a way to check the result, whether you're working out what to build or reviewing a pull request. The collection covers engineering, productivity and UI/UX, and I keep improving it as I use it.

They are the portable part of the workflow above. Your project's knowledge and connected tools stay in your environment, and its conventions take precedence. You can use one skill without adopting the whole setup.

A few places to start

Try a small selection

From your project directory, install the router, task planning and verification skills for Codex. Review the install summary before confirming. 

bunx skills add bobalazek/skills \
  --skill choose-skill create-tasks verify-change --agent codex --copy

Then give the router your task in Codex:

$choose-skill I have an agreed spec. What should I do next?

The README covers the other installation options and updates, and the repository keeps the full catalogue and workflow guides in one place.

Browse the skills → Workflow guide →

Controls around the model calls

The same few controls come up across these systems. Each one links to where it runs.

Writing about it

Posts that go deeper into these systems and the workflow.

Want this on your team?

Bring me into your team for a role, or work with me on a scoped AI pilot through Corco Labs.

An engineering role

Hiring for a long-term role, employed or on a B2B contract? Send me the role description.

Discuss a role

An AI consulting pilot

One workflow in your product or engineering team, with evaluation, training and a documented handover.

Explore consulting through Corco Labs