An AI demo always works. Production asks the harder questions: who may call which tool on whose behalf? What happens when a call fails? What does one user cost per month? I build the infrastructure behind agentic systems: MCP servers, controlled tool access and LLM integration into the backends you already run.
Feasibility as a self-contained one to two week engagement. The production build typically runs two to four months, with an explicit option to stop after feasibility.
Remote from Germany. Straight with me, no agency in between.
An agent that works in a notebook is not a product. The moment real users, real data and real permissions enter the picture, the problem shifts. It stops being about prompts and starts being about identity, access rights, traceability, failure behaviour and cost per request.
The critical part of an agentic system is rarely the model. It is the tools: what an agent may do on behalf of a user, how that is actually enforced, and how you find out afterwards what really happened. That is where I work.
Typical symptomsFirst the uncomfortable question: does this actually need a model? Some of it is a search function, some of it is a rule. If an LLM is the right answer, we define up front what „good enough" means and how it gets measured.
Your existing systems are exposed as tools over MCP, with clearly bounded capabilities. Every tool has a signature, a permission check and defined failure behaviour. No model gets direct database access.
The agent acts on behalf of one user, not on behalf of everyone. OAuth 2 through Cognito, a token broker for downstream systems, and permissions checked where they belong. Every tool call maps back to a person.
Token consumption per user and per use case, hard limits and budgets, caching for repeat requests, smaller models where they suffice. Plus timeouts, retries and a clean fallback when a provider goes down.
Test sets built from real cases, automated evaluations in the pipeline, regressions visible before release. Changing a model or a prompt becomes a decision backed by numbers instead of a gut call.
Stopping is part of the process. After feasibility you know whether the production build pays off, and you are allowed to say no.
Use case, data situation, expectations. If a model is not the right answer, I say so in the call rather than three months in.
A prototype on your real data, quality measured against a baseline, and a cost estimate per request.
MCP server, tool integration, auth and audit trail. Deployed on AWS through Terraform, like any other service.
Evaluations in the pipeline, cost and quality dashboards, handover to your team including pairing.
Every tool call has a user, a checked permission and a log entry.
Consumption visible per use case, limits in place, expensive calls caught before they become habit.
Models and providers can be swapped without rebuilding the application.
The Model Context Protocol is an open standard for how a model talks to external systems. An MCP server exposes your systems as clearly defined tools, each with a schema, a permission check and defined failure behaviour. The benefit: you control what an agent may do in one place, instead of copying that logic into every application.
Not necessarily. Through Amazon Bedrock, calls stay inside your AWS environment and region. Which data reaches a prompt at all is decided at the tool level and logged. That is part of the design, not a setting flipped at the end.
Through measurement and limits: token consumption per user and use case, hard caps, caching for repeat requests, and smaller models where they are good enough. The cost estimate comes out of the feasibility phase, before anything is built rather than when the first invoice lands.
Yes, and that is a common starting point. The prototype usually answers whether it works in principle. What is missing is the path into operations: identity, permissions, failure behaviour, evaluations and cost control. That layer is what I build.
Then we say so after the feasibility phase and you have spent one or two weeks instead of two quarters. A well-argued no is a legitimate outcome, and considerably cheaper than a project nobody wants to cancel.
Replacing manual workflows with real systems: wired into the software you already run, with permissions and an audit log instead of a chain of tools.
Learn moreI find where your AWS budget leaks away, and cut it measurably without giving up performance or availability.
Learn moreFrom your own data centre or another cloud onto AWS, with a cost model before the move and a rollback path for every step.
Learn moreModernizing grown systems step by step: strangler fig instead of a rewrite, operations untouched, every step reversible.
Learn moreBackends for SaaS and platforms that hold under real load: Go and PHP 8, event-driven, with tenant isolation and recovery designed in.
Learn more