GOD-LIKE SOLUTIONS

Philip Prstojevic — applied AI, R&D and agent systems

I'm a software developer based in Eskilstuna, Sweden, working on applied AI and R&D. I take on problems where the source material, rules and workflows aren't well structured yet — I build the tools needed to investigate them, then turn the approaches that hold up into systems people can actually use.

Right now

Since July 2026 I'm Lead AI Consultant at Axle AB, the sole consultant on an engagement where I own the whole delivery: scoping, the client relationship, architecture, development and deployment. I'm building Eltec Assistent, an AI operations platform for an electrical contractor, intended as the foundation of a SaaS product for the installation and construction sectors.

The core idea is safety-first agentic automation: the language model reads and proposes, while deterministic, versioned business rules perform every change — each write behind a user-approved plan, preflight checks, a restorable pre-image and an append-only audit trail.

Before that

• Ahrens Optimate (2026) — Lead Developer, building document analysis and tender-preparation systems for architectural and construction tender material: AI extraction with source evidence, selective OCR pipelines and semantic search across project files.
• Freelance data acquisition (2018–2025) — crawlers, scrapers and API integrations for messy, inconsistent data sources.
• Dataset engineering for image-generation training data, and insurance data systems for automated collection and evaluation.

What I care about

Source-grounded results, explicit uncertainty, and systems that can be inspected and maintained. On the side I research agent orchestration, associative memory for agents, and code graphs as agent tooling.

Read more

• The model proposes, the rules write: building Eltec Assistent
• Evidence over confidence: document analysis for construction tenders
• Harness engineering: the system around the model
• Flashback: associative memory for agents
• Twelve years of messy data: from scrapers to agents

Contact

Email philip@prstojevic.se or find me on GitHub. I'm happy to talk about applied AI roles, projects and collaborations — Stockholm–Mälardalen or remote.

From needs analysis to production, with one person accountable

I work through my consultancy, Axle AB. On an engagement you deal with the person who builds the system, from the first meeting to deployment.

1. Needs analysis, on site. I sit with the people doing the work and map where the hours actually go. Not where a slide says they go.
2. A proposal with a hypothesis, not a promise. You get a written proposal and specification with a stated, measurable hypothesis, such as "this much admin per month can be removed". We test it on representative cases before and after. I won't sell you a saving I haven't measured.
3. Build in small, usable steps. The first useful piece goes live early, and the rest grows around real feedback. Your existing system stays the system of record.
4. Safety and traceability by default. AI proposes, rules execute, and every change can be inspected and restored. That's not an add-on. It's how I build.
5. Production engineering included. Automated tests, CI/CD, encrypted backups and a rehearsed restore. You get a system you can live with, not a prototype you're stuck with.

Where

I'm based in Eskilstuna and happy to work on site across Mälardalen and Stockholm, or remotely. I work in Swedish and English.

Get in touch

Email philip@prstojevic.se with a short description of the problem. I'll reply with questions or a suggested first step.

AI operations platforms for small businesses

Most small companies don't need a new system. They need the hours back that disappear around the one they already use: reconciling rows, chasing approvals, checking supplier invoices, remembering what should have been billed.

I build AI operations platforms that sit on top of your existing business system and take that recurring administration off people's desks, without putting your records at risk.

What you get

• Overviews that answer the real question, like "what's billable and waiting on approval right now?", kept in sync with your system of record.
• Automated chores with a human in the loop. The software prepares the change, shows a before/after view, and you approve it.
• A chat assistant that answers questions about your own data (orders, time reports, assignments), with the source shown for every answer.
• Safe writes back into your system. The language model reads and proposes, and deterministic, versioned rules make every change. Every write gets a preflight check, a restorable pre-image, a read-back and an audit trail.
• Access control decided per role and per user, so sensitive fields like financial data stay out of the model's context.

Good fit if

• You run on a field-service, ERP or order system that works, but the admin around it eats days every month.
• You want to know what changed and why after any automated action.
• You're a small installation, construction or service company. That's where I've done this in production.

Proof

This is exactly what I built for an electrical contractor on top of Fieldly: The model proposes, the rules write.

Turning piles of PDFs into data you can check

Tender packages, drawings, specifications, scanned forms. If your team spends hours reading documents to pull out the same kinds of facts, that work can be structured. It just has to stay checkable.

What I build

• Extraction with evidence. AI proposes values together with the page and passage they came from, and your people confirm them in a review interface. Nothing reaches a quote or a report unconfirmed.
• Selective document pipelines that read what's already in the file (structure, embedded text, vector graphics) and only fall back to OCR or table extraction where it's actually needed. That makes them faster, cheaper and more accurate than OCR-everything.
• Semantic search across mixed project files, where every hit links back to document, page and text.
• Drawing and floor-plan parsing, like room labels and square metres from floor-plan PDFs, matched against your own quote templates.
• Evaluation: dataset exports and holdout tests, so you know how well the extraction actually performs.

Good fit if

• Your documents are inconsistent, mixed-format or partly scanned.
• Wrong numbers are expensive, so people need to see why the system thinks something.
• You want something your team will actually use, not a demo.

Proof

I led this work for architectural and construction tenders at Ahrens Optimate: Evidence over confidence.

Agents that are allowed to do things, safely

Getting a model to call a tool is easy. Getting an agent to do useful multi-step work inside a real business, and being able to show afterwards exactly what it did, is the hard part. That's the work I specialise in.

What I build

• MCP servers that expose your systems to AI assistants and third-party tools. They come with OAuth, per-recipient output schemas that decide what each consumer may see, and source and freshness metadata on every result.
• One capability registry for every channel, so your in-app chat, admin tools and MCP clients share the same typed tools and return the same answers, with parity tests to prove it.
• Guarded write pipelines: approved plans, expiring confirmation tickets, preflight checks, restorable pre-images, read-back and append-only audit trails.
• Agent orchestration: explicit control over each step's instructions, tools, memory and completion criteria, so runs are predictable and comparable.
• Evaluation and logging, so you can tell whether a change to prompts, tools or models actually made things better.

Good fit if

• You want to connect AI assistants to internal systems without handing them the keys.
• You have an agent prototype that works in a demo but isn't trustworthy enough for production.
• You need agents that work across several models, including local ones.

Proof

In production for a client: The model proposes, the rules write. In my own R&D: Harness engineering and Flashback.

Own the integration, not just the login

Most businesses depend on platforms they don't control: vendor portals, SaaS tools, supplier systems, marketplaces. The platform decides what you can see, what you can export, and what it collects about you in return. The "integration" is whatever the vendor feels like offering.

It doesn't have to be. The browser and the app already talk to an API. It's just not documented for you.

Reverse engineering web APIs

I map the APIs that web and desktop clients actually use: endpoints, authentication flows, payloads, pagination, rate limits and the undocumented fields that matter. The method is simple and devastatingly effective: record real client traffic as HAR files from the browser's dev tools, and let a large language model help read it. I verify every finding, then build on it with stable, tested client code. You get reliable programmatic access to your own accounts and data, even where no official API or export exists.

Reclaiming client-side integrity

Every client you run also sends data: telemetry, identifiers, behavioural signals, metadata you never agreed to think about. I analyse what your clients and integrations give off, and build replacements or intermediaries that send only what's needed, on your terms.

Complete control of the data flow

• Collect exactly what you need, in a structured form, with source and freshness recorded.
• Discard what you don't, deliberately and at the edge, before it lands anywhere.
• Give off only what the relationship requires, and know precisely what that is.
• Mirror external data into stores you own, rebuildable at any time, so a vendor change doesn't take your operations down with it.

Control the relationship and the contract

When you know exactly how a platform works and what it exchanges with you, you negotiate from knowledge instead of dependence. You can switch vendors, hold them to what they promised, or decide you don't need them.

Background

Years of building crawlers, scrapers and API integrations against inconsistent, undocumented and changing sources, in Python with Scrapy, Beautiful Soup and Requests, and these days browser dev tools, HAR recordings and LLMs: Twelve years of messy data.

Building Eltec Assistent: an AI operations platform for an electrical contractor

Since July 2026 I've been the only consultant on an engagement through Axle AB for Eltec, a small electrical contractor in Mälardalen. I ran the needs analysis on site, wrote the proposal and specification, and own the architecture, code, tests and deployment. The client talks to the person who builds it.

The problem

Eltec runs its orders, time reports, materials and supplier EDI through the field-service system Fieldly. The records are fine; the work around them is not. Before anything can be invoiced, someone has to find which orders carry billable value awaiting approval, reconcile article rows reported three times for the same product, work out how supplier EDI lines relate to what the customer is billed, and remember the service-vehicle mileage for every visit.

The needs analysis mapped roughly 86 hours a month of this kind of recurring administration. The proposal set a working hypothesis that about 56.5 of those could be removed or sharply reduced. It's still a hypothesis, not a result. The before/after measurement isn't reported yet, and I'd rather say so than round it up.

The hard constraint

Fieldly is a third-party system of record. Every automated change has to be as safe as a careful person doing it by hand, and every answer has to show where it came from. That decided the whole design:

• The LLM reads and proposes. Deterministic, versioned business rules perform every change. The model never holds the pen for prices, quantities or records.
• Every write is guarded. A change starts as a user-approved plan with a before/after view, is bound to an expiring confirmation ticket, passes a live preflight against Fieldly, stores a restorable pre-image, is read back after execution and lands in an append-only audit trail. Uncertain outcomes are never retried automatically.
• Provenance is mandatory. Every result carries source, freshness and coverage metadata. If a source changes mid-read, the result isn't released.
• Access is decided in the backend. Roles, per-user deny overrides and per-recipient output schemas decide what the browser, the model and MCP clients can see, which keeps financial fields out of model context.

What it does

• A live order overview showing billable value awaiting approval.
• Article-row consolidation: 2 + 3 + 5 of the same article become one billable row, with history and exact restore.
• EDI supplier-invoice handling, where originals are excluded rather than deleted so restore is exact.
• Mileage billing computed via Google Routes under a versioned rule and applied through the same confirmation flow.
• A chat assistant and an MCP server over one typed capability registry, with parity tests proving both return identical results. An OAuth-secured MCP server for third-party integrations is built and tested, awaiting deployment.

Under the hood: FastAPI and PostgreSQL with a durable store and a rebuildable mirror of Fieldly, a transactional outbox feeding recalculation workers, digest-pinned CI/CD and a pull-based release controller that takes an encrypted off-host backup before every migration. About 60k lines of Python and 900+ automated tests. I built it alone.

What I learned

The interesting engineering wasn't the model. It was deciding exactly where an LLM may act in a system someone else owns, and how to prove afterwards what happened. Most of the code is guardrails, provenance and recovery. That's why the client trusts software with their invoicing data.

The platform is intended to become a SaaS product for small installation and construction companies. Client specifics live in configuration and versioned rules. The registry, guarded writes and release machinery are generic.

Document analysis for construction tenders

From March to July 2026 I led development at Ahrens Optimate on document analysis and tender preparation for architectural and construction material. Tender packages are a good stress test for AI: hundreds of mixed files, drawings next to spreadsheets, scanned pages next to clean PDFs, and numbers that end up in a priced quote.

Proposed, not decided

We built a Django and React workflow covering tender intake, review of extracted facts, pricing, quotation generation and follow-up. The key decision was who gets the last word. AI extraction proposed values together with the source evidence behind them, and users confirmed the final values.

That sounds like a small UX choice. It's actually what makes adoption possible. A tool that's wrong without showing why doesn't get used. A tool that shows the page, the passage and the reason gets corrected, and then trusted.

Read the document before you OCR it

OCR on everything is slow, expensive and often worse than what's already in the file. So I designed a selective document pipeline. It looks at structure, embedded text, objects, vector signals and raster content, and from those decides when OCR or table extraction is actually needed. A native PDF with a clean text layer shouldn't be treated like a fax.

Search you can follow back

Vec2Offer is semantic search across mixed project files. Every candidate is source-linked at document, page, evidence and text level, so an answer always leads back to where it came from.

Measuring instead of hoping

For the supervised parts I produced dataset exports, built centroid classifiers on frozen embeddings and ran holdout evaluations, to show what the models actually did rather than what they seemed to do. I also prototyped extraction of architectural symbols from drawings, combining vector geometry, template methods, OCR and a compact CNN in PyTorch.

The thread

Messy source material, a structured result and a human who can check it. That pattern has followed me from data acquisition work to this, and on to Eltec Assistent.

The system around the model

When an agent does something stupid, the model is rarely the whole story. Usually it got the wrong context, the wrong tools, no clear idea of when it was done, or no memory of having solved the same thing yesterday. Harness engineering is my name for working on that part: context, tools, multi-step work, memory, logging and evaluation. It's the part of AI I care most about, and most of my own R&D time in 2026 has gone into it.

A model-agnostic harness

The base layer is a single execution path for both API models and CLI agents. It has shared tools, normalised events, sessions and interruption handling. Once every model speaks the same event language, you can swap models, compare them on the same task and log runs in one format. That last part matters more than it sounds, because the logs become data (see Flashback).

Agenda Protocol

On top of the harness sits Agenda Protocol, a deterministic orchestration data structure. Turn by turn, it decides:

• which instruction the agent gets,
• which tools it may use,
• which memory it can see,
• and what counts as done.

Protocols can be nested, so a step in one protocol can be a whole protocol of its own. Versions can be compared against each other on evaluated outcomes, and the protocol can be refined autonomously from those results. The model stays free to reason, but the shape of the work is explicit, inspectable and versioned. That's the same principle as in my client work, where the model proposes and the rules write.

A code graph agents can use

Agents working on code waste a lot of turns rediscovering structure. So I built a graph of a codebase from its abstract syntax trees. It works as an agent tool, answering questions about dependencies, change impact, symbols, call paths and version diffs. It also works as a visual overview for the humans on the project. Both use the same data.

Why deterministic?

Non-determinism belongs where it's useful: reading, interpreting and proposing. Everything else (what the agent is allowed to touch, how its work is checked, how we know it improved) should be boring, repeatable and testable. Next on my list is trying all of this against ARC-AGI-3.

Associative memory for agents

People don't solve a familiar problem from scratch. Something about the situation reminds us of last time, and we remember roughly what we did and how it turned out. Most agents don't get that. Every run starts cold.

Flashback is my attempt to give agents that kind of situational memory.

How it works

For the agent's current state, an embedding model retrieves the top-k most similar historical turns. Each comes with its context, the actions that were taken and the trajectory that followed. The agent doesn't just see "a similar situation happened". It sees what was done and where it led.

The memory is built passively. Whenever a harness run happens, its turns are logged in a normalised format and become searchable. Nothing has to be curated by hand.

Strong models teach, small models reuse

This is the part that interests me most. Trajectories built up by stronger models can be reused by small, locally hosted models, without changing their weights. A small model that can recall how a strong model handled a near-identical situation punches well above its size. Making local, open-weight models genuinely useful is, to me, mostly a harness problem, and memory is a big piece of it.

The same memory doubles as a dataset: collected (state, action, outcome) trajectories are exactly the material you want for distillation and fine-tuning, if you decide to go that way later.

Open questions

• How do you weight a remembered trajectory that failed? It's useful as a warning, but risky as an example.
• When does similarity in embedding space actually mean similarity in task structure?
• How much memory helps before it starts crowding out the actual problem in the context window?

These are what I'm testing now.

From scrapers to agents

Long before "AI engineer" was a job title, most of my work was about the same thing it's about now: taking sources nobody designed for you and turning them into something structured, trustworthy and useful.

Insurance data (2014–2016)

At Wedevia I built and operated systems for automated collection, review and evaluation of insurance data, using live retrieval and backend orchestration. That's where I first learned that the review step is part of the system, not an afterthought.

Training data for image generation (2019–2021)

With Crowdfounder / Rapagram I built extraction and annotation pipelines for image-generation training data. The lesson there: bad artists copy, great artists steal. A model fed copies learns the surface. What you want it to take is what makes the source work, so the real job was choosing sources, cleaning them, and labelling the things that actually matter.

Freelance data acquisition (2018–2025)

For years I designed crawlers, scrapers and API integrations for sources that were inconsistent, undocumented or actively changing, in Python with Scrapy, Beautiful Soup, Requests, regular expressions, pandas and Matplotlib. Postman came and went. In the end the browser's own dev tools were all I needed: every request the client makes, right there in the open. Sometimes the data is the easy part, and you spend most of your time on what a field actually means this week.

Then the models matured, and the game changed. Record a session as a HAR file, hand it to a large language model, and the API is mapped in minutes: endpoints, auth flow, payloads, pagination, the odd undocumented field. I'm not downplaying it when I say that recording client-side requests and reading them with an LLM is probably the greatest thing AI has given engineering. If people only knew. Anyone who really understands what a browser is has taken hold of something like a skeleton key to the internet.

What carried over

Every one of those jobs had the same three questions, and they're the same questions I ask of LLM systems today:

1. Where did this value come from? That became mandatory provenance in Eltec Assistent.
2. How sure are we? That became source evidence and human confirmation in tender analysis.
3. What happens when the source changes? That became freshness checks, rebuildable mirrors and holdout evaluations.

Models got dramatically better. Sources did not get any tidier.