Current context
01 / trust surface
About
Internal AI systems, judged by whether they hold up in real use.
I work on internal AI systems for concrete enterprise workflows: decision-support tools, internal assistants, RAG systems and prototypes that need to become reviewable enough for real users.
The useful question is rarely whether an AI feature can be demonstrated. It is whether the workflow, evaluation, access boundaries, cost visibility and handoff are clear enough for the system to survive contact with actual work.
My current work is in applied AI for internal industrial workflows in an enterprise setting. That context matters because internal AI work is usually constrained by ownership, access, review paths, data quality, operational cost and what the team can actually maintain after launch.
This site keeps that same bias. The work starts from the workflow, not from a model choice. Some workflows need a constrained AI layer. Some need a better retrieval setup and review path. Some need classical automation, better data plumbing or no AI system at all.
02 / fit
What I work on
The strongest fit is project-based work around internal systems with a concrete owner, users and constraints.
Decision support
Workflows where analysts assemble context before recommendations or decisions.
Internal assistants
RAG systems where access, retrieval quality, feedback loops and ownership matter more than the chat interface.
Prototype hardening
Demos that work but still need evaluation, observability, cost, review or handoff discipline.
Scoped advisory
Cases where the useful answer may be build, harden, simplify or stop.
How I judge the work
Less demo optics, more operating judgment.
I care less about whether a system looks impressive in isolation and more about whether it can be operated, reviewed and owned.
Checks
- what workflow the system changes
- who owns the workflow and who uses the output
- how mistakes are detected and reviewed
- where access boundaries sit
- how cost is visible at workflow level
- what is left behind for the team after delivery
03 / proof
Proof
The public proof base is narrow, but the signals are different.
The public cases come from in-house enterprise work. They should be read by signal type: workflow outcome, operated system and delivery discipline.
Workflow outcome
~75% faster · 4.4/5 · 90%+
Credit-risk decision-support workflow with structured recommendations and analyst review retained.
Read credit-risk case →Operated system
300+ users · 85%+
Self-hosted internal assistant with scoped access, feedback review, operator/admin surfaces and usage/cost visibility.
Read assistant case →Delivery discipline
Public repo
The Agentic Development Playbook shows scoped tasks, verification before commit and migration guidance. It is supporting proof, not the main delivery proof.
View Playbook →How to read this site