How we
work together.
Most AI tools impress in a demo, then stall the moment real work hits them. I build the opposite: systems that get more useful with age, because they're grounded in evidence, shaped around how you actually work, and built to keep paying back long after the pilot.
Everything I do runs on the same engines I build in the open, webdevOS and cofounderOS. The four practices below are how I put that discipline to work for you.
New to this? Take the 2 minute diagnostic to see where you are.
Agents You Can Trust
Claude Code is inconsistent. It sends me down rabbit holes.
Claude Code is brilliant on a good day and, on a bad one, leads you down rabbit holes that cost more than doing the work yourself. The inconsistency is the real problem: you can't plan around a tool you can't predict.
It starts with a discovery call, focused on where your agentic work is breaking down, because you're already running Claude Code for real work. Consistency comes from context engineering, not luck. I work as a forward deployed engineer (FDE): I embed with you, engineer the context the agent works inside, and ship it as pre-built, versioned, self-healing configuration, not a pile of one-off scripts. The same discipline maintains this very site, and if your domain is web development, I can deploy webdevOS itself.
You get agentic work you can actually rely on, so bringing in an agent becomes a decision rather than a gamble.
- D.01A context-engineering layer across your agentic workflows, adding determinism where it matters most.
- D.02Pre-built, versioned configuration you can see and trust.
- D.03Self-healing guardrails so the agent recovers cleanly.
Claude Code is inconsistent: great some days, a rabbit hole on others. Why?
Inconsistency is almost always a context problem, not a model problem. When the agent doesn't have the right context engineered around it, it improvises, and improvisation is where the rabbit holes start. Fix the context and the behaviour becomes predictable.
How do you make agentic work dependable rather than a gamble?
Through context engineering shipped as pre-built, self-healing, versioned plugin configurations, not a pile of one-off scripts. Versioning means you know exactly what the agent is running; self-healing means it recovers cleanly instead of spiralling. Together they turn an unpredictable assistant into something you can plan around.
What is webdevOS and why does it matter here?
webdevOS is my own web-development toolkit, and it's the proof point for this approach: the same discipline of versioned, self-healing configuration that I bring to your agents. It's evidence that the method produces consistent, dependable agentic work in practice, not just in theory.
Will the configuration still make sense after you leave?
That's the intent: because it's versioned and documented, you can see what it does and extend it yourself. Education and enablement are at the core of what I do, so the handover leaves your team able to run and extend the config rather than inheriting a black box. In some cases an ongoing retainer makes sense to keep the system effective as it evolves.
Not sure which fits?
The four practices map to the four stages of adoption. Most people start with Find the Value and grow from there.