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
Three signals from real internal AI work.
One case shows measured change in an analyst decision-support workflow. One shows an internal assistant operated with access, feedback, usage and cost controls. The Playbook shows how I approach verification, review and acceptance in AI-assisted software work.
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 →Engineering judgment
Public protocol
The Agentic Development Playbook is a small written software change-acceptance protocol for agent-assisted development. It sets out how I distinguish check results, judgment from any required review and the authority to accept a specific change for merge, release or deployment. The core protocol is defined and maintained; platform-specific guidance remains limited.
View Playbook →