Software architect AI systems Roosendaal, NL
Systems that hold up.
Models that behave.
I design backend, mobile and API systems for enterprises, and build the tools and context that make LLM agents reliable in production. When an agent fails, I fix the system around the model first.
How I build
Boring where it can be, novel where it must.
Proven infrastructure underneath, invention only where it changes the outcome. Novelty is a cost to be spent deliberately.
Contracts outlive the code inside them.
APIs, schemas and boundaries between systems are the durable design. Frameworks are replaceable; interfaces are not.
If you cannot inspect it, you cannot fix it.
Traces, structured logs and evals are part of the product. This is doubly true for anything with a model in the loop.
Fix the system around the model first.
Context, tools and orchestration are cheap to change and easy to test. Fine-tuning is neither. Start where the leverage is.
Fix the system around the model before the model.
Most agent failures are not model failures. They come from what the model was shown and what it was allowed to do. Pick a failure to see where it originates in the loop and the cheapest layer that fixes it.
Answers from stale or missing facts
The fact the model needed was never in its window. It filled the gap the only way it can: by guessing.
Retrieve and inject the data. Add freshness metadata to results and tell the model what it does not know. No weights involved.
Picks the wrong tool
Two tools overlap, or their descriptions read the same to a model that only sees text. Ambiguity in the schema becomes ambiguity in behaviour.
Fewer, sharper tools. Name them by intent, describe when not to use them, and include one example call in the schema.
Invents an argument or ID
The tool accepted a free-form string where the valid values were known. The model produced something plausible instead of something real.
Constrain with enums and typed IDs. Return the valid IDs in earlier tool results. Validate and reply with an actionable error the model can act on.
Returns the wrong format
The expected shape lived in the developer’s head, not in the prompt or the schema.
Structured output with a schema, a validator, and one bounded retry. A format failure should never reach a user.
Loops or gives up midway
No explicit success criterion and no budget. The loop has no way to know it is done, or that it is stuck.
Define done. Cap steps, checkpoint state, detect repeated calls, and hand off to a human with the trace when the budget runs out.
Still wrong after all of the above
The failure is stable across prompts, measured by an eval suite, and rooted in domain knowledge or style the base model lacks.
Now fine-tune, on data collected from the fixed system. Keep the tools and context: they are what made the failure legible in the first place.
Fine-tuning is the last rung. It is slow, it freezes behaviour into weights, and it is only justified when the failure is stable, measured, and out of reach of the three layers above it.
What I work with
- C#
- PHP
- Kotlin
- JavaScript
- Java
- .NET
- Laravel
- Next.js
- Node.js
- Unity
- Tailwind CSS
- MSSQL
- MySQL
- PostgreSQL
- MongoDB
- Firebase
- Azure
- Linux
- Windows
- Android
- Active Directory
- LLM APIs
- Tool calling / MCP
- Retrieval (RAG)
- Evals & tracing
- Agent orchestration