On AI
My perspective on AI: building systems that enhance human capability and organizational effectiveness. AI is a strategic tool. How we deploy it shapes competitive advantage.
Artificial Intelligence is transformative and carries great promise. We are building and experimenting better than ever before, learning in new ways, and finding productivity gains that could've only been imagined a few years ago.
As a dad in the midwest, it doesn't matter much to me how AI impacts me - but it matters a whole lot how it'll impact my little girl. I want human-AI collaboration to enhance learning experiences and give time - our most precious resource - back to our families.
How I Evaluate Model Output
This is the first thing anyone asks an AI product manager, so here is the answer with the code behind it. Everything below runs in the multi-agent system I built for my thesis instrument, and every item names the file it comes from.
There are no pass rates, benchmark scores or hallucination rates on this page. The study has not run yet, so I do not have any, and a number I invented would be worth less than nothing. What I can show is the method: constrain what a model is allowed to return, put a second model in the loop whose job is to argue against the first, make every degraded path label itself, and measure the outcome with something that is not a model.
Two of the three agents answer through a schema, not prose
The worker returns against a JSON schema in strict mode, so the proposed level comes back as an integer and the direction as one of four enum values or the call fails. The antagonist runs as a forced tool call against a schema of its own, with a text-parsing path behind it for the case where a response ever arrives outside the tool. The orchestrator is the exception and I will not pretend otherwise: it is prompted for raw JSON and parsed, which is exactly why it needs the fallback further down.
- server/services/owa/scaffoldAgents.ts
A second model in the loop whose job is to object
The antagonist gets the worker's proposal and a learning theory knowledge base, and answers through a forced tool call. The schema requires the approve or object verdict, and constrains the principle it cites to three values: cognitive load, zone of proximal development, or expertise reversal. It cannot invent a fourth. It can object without citing one at all, because that field is optional, and those arrive as null. The theory text is one versioned constant in the repo rather than a prompt edited in place, though the version is not yet stamped on each decision.
- server/services/owa/scaffoldAgents.ts
- server/services/owa/knowledge/learning-theory.ts
Every number a model produces is clamped before anyone sees it
Scaffold levels are forced into the range 1 to 3 in code after the model answers: on the worker's proposal, on the antagonist's suggested alternative, and on the orchestrator's final level. A model that returns 7 does not produce a level 7 screen. It produces a level 3 screen.
- server/services/owa/scaffoldAgents.ts
Degraded output labels itself
When the orchestrator's response will not parse, a deterministic rule sets the level from the worker's proposal and the antagonist's verdict, and the decision is flagged as a fallback rather than passing as model output. The route writes an incident row when that happens. Those decisions can be pulled out of the analysis afterwards, which is only possible because they are marked at the moment they occur.
- server/services/owa/scaffoldAgents.ts
- server/experiment-routes.ts
One primary attempt, one fallback model, then stop
Each role has a named fallback model on a different generation of the same family. The call helper makes one attempt on the primary and one on the fallback, and that is the whole budget at that level. Above it the whole decision gets a bounded number of tries with exponential backoff between them: at most two on Vercel and three locally, so one retry in production and two in development. The attempt that finally works is not the only one recorded, because every attempt that fails writes its own row before the next one starts.
- server/services/owa/scaffoldAgents.ts
- server/services/owa/config.ts
- server/experiment-routes.ts
Every failure writes a row, not a log line
An incident row names the agent, the error type, which attempt failed, and whether the session ended. Logs get rotated and nobody reads them. A table can be counted, joined against the run it came from, and exported with the rest of the study data.
- shared/schema.ts
- server/experiment-routes.ts
A run that cannot be trusted is excluded, not quietly downgraded
If the adaptive path cannot produce a decision after its retries, the session terminates and the participant is marked for exclusion. It never falls back to the fixed schedule the control condition uses. Substituting one condition for the other would put a control experience under an adaptive label, and nothing in the data afterwards would show that it happened.
- server/services/owa/scaffoldSelector.ts
- server/experiment-routes.ts
The outcome measure is not a model
Whether a learner got a loop task right is decided by running their Python and comparing stdout to the expected output after whitespace normalisation, not by asking a model to grade it. The models decide how much help to give. They do not get to mark their own work. The posttest coding item is the exception and I am not going to dress it up: it is stored unscored, and the rubric fields on it stay empty until I build the scoring.
- server/services/pythonExecutor.ts
- server/experiment-routes.ts
Cost and latency are recorded per role, per session
Prompt and completion tokens accumulate per agent per participant, and every decision records its latency and which model actually served each role. A fallback is visible in the data as a different model id, not as a gap.
- server/services/owa/tokenTracker.ts
- server/services/owa/scaffoldAgents.ts
The failure paths are the ones with tests
Malformed JSON, a response wrapped in a code fence, a primary model that throws and a fallback that also throws are all covered by unit tests, because those are the paths that only run when something has already gone wrong and would otherwise be discovered in front of a participant.
- tests/server/owa-scaffold.test.ts
The non-determinism policy
The same learner history can produce a different decision on two different days. That is a property of the system, not a defect in it, so the policy is to fix everything that does not need to move, let the rest move, and record enough that any single run can be reconstructed afterwards.
Pinned
- Which model serves each role, and the named fallback behind it
- Sampling temperature, set at the call site: 0.3 on the worker and on the orchestrator
- A token ceiling on every call, so a runaway response is cut off rather than paid for
- The legal output range, clamped to 1 through 3 in code after the model answers
- The learning theory text the antagonist argues from, behind a version string
- The performance window a decision is computed from: the last two responses
- The control condition, which is a fixed level 3 to 2 to 1 schedule with no model in the path at all
Allowed to vary
- Which model actually served a role on a given call, primary or fallback
- The prose: the worker's reasoning, the antagonist's objection, the orchestrator's rationale
- Latency and token counts per call
- The decision itself. Two learners with the same history can get different levels, and designing as though they will not is how teams get surprised in production.
Recorded, so a run can be reconstructed
- Previous level, proposed level, final level, and direction
- The worker's proposal, the antagonist's objection with the theory it cites, and the orchestrator's rationale
- The accuracy window the decision was computed from
- The model id that served each role, and the decision latency
- The deterministic fallback flag, on the decisions that used one
- An incident row per failure: agent, error type, attempt number, whether the session ended
- Per-agent token totals for the session
What this does not have yet
- No offline eval set. There is no held-out set of performance histories with expected decisions, so I cannot tell you how often the orchestrator agrees with a human expert.
- No fallback rate. The incident table can answer how many decisions in a hundred came from the deterministic rule. The number does not exist yet because no participants have run through it.
- No agreement measure on the antagonist's objections. Nobody has coded a sample of them against the theory they cite.
- No latency distribution. Latency is recorded per decision and logged per phase, but with no runs there is nothing to take a p95 from.
- No automatic score on the posttest coding item. The response is stored and the five rubric fields exist on the row, but nothing fills them in yet, so that item gets coded by hand until I build the scoring.
Each of those comes out of the fields already being recorded, once there are runs to compute them from. Until then this page says what it can support and nothing else.
My AI Philosophy
AI is a tool, not a search engine
Most people today still treat AI like a search engine instead of as a tool. Where many leaders shift the narrative to say "AI instead of people," I believe strongly that AI productivity + human creativity is how we get the most out of the technology. Use it wrong and you end up with AI slop. Use it correctly, and you get more done with better judgment.
Blind trust destroys credibility
Many people trust AI blindly, copying and pasting ChatGPT speak with emojis they've never used before onto platforms like LinkedIn. AI can be an effective writer, but it also has to sound like you and be grounded in fact. One hallucination copied and pasted into a social platform will immediately turn a thought leader's credibility upside down. This is the core thesis behind Ember: generating content in a user's voice, grounded in research around topics they actually care about.
Physical AI is underhyped
If I train an AI on only contextual information from the web, my results will be mixed. Just think: Facebook is 60% of somebody's uncle's political rants, and 50-60% of the content on StackOverflow is code that didn't work. Physical AI (wearables, AR glasses, robotics, handheld devices) brings context that doesn't exist in these tools today. People are generally more pleasant and thoughtful in face-to-face interactions. This context powers better outcomes through connected systems.
Small language models are the future
Most of the AI hype is around LLMs, but small language models will actually be more effective across vertical tasks in important fields like computer science and medicine. The biggest leap in AI comes from smarter placement of the model, rather than a larger model. Think mobile phones and smart watches instead of mainframes.
This philosophy directly shapes my strategic work: Ember explores how to scale authentic voice responsibly. My partnerships with frontier autonomous companies focus on how autonomous technology integrates into human-centered operations. Every initiative reflects this conviction: AI should enhance human capability and how much an organization gets done, instead of replacing the people and cultures that make great companies what they are.
What Concerns Me About AI
Guardrails are critical
I see firsthand people taking AI slop and trusting it as if it's gospel. AI has propelled ads, spam, and malicious content alongside all of the good we've gotten from it. AI doesn't know if it's "helping" by pen-testing a developer's benign software or if that developer is actually instructing it to exploit a new zero-day to attack a bank. The technology needs thoughtful guardrails.
The knowledge atrophy problem
Having AI do EVERYTHING for you is bound to cause an ultimate loss of knowledge. I've seen students submit AI-written essays or research contributions, and I've seen where hallucinations have caused them to get it wrong, or they can't complete a test or answer basic questions in a field because they didn't do the work. ChatGPT did. We must learn to work WITH AI, not have AI do everything for us.
The Human Future
Humans become orchestrators
Humans will move more into an orchestration role, enabling them to 10x productivity if they use these tools effectively. AI can give us more time back to spend on the human things we love, like time with our families and friends. If used effectively, we can learn, build, dream, and do it all faster.
Relationships remain everything
I believe relationships are today, and still will be, the single most important thing in our lives. The Harvard Grant Study, one of the longest studies of adult life ever conducted, confirms this: close relationships, more than money or fame, are what keep people happy throughout their lives. AI should serve this truth, not replace it.
On Agentic Development
We're all learning this together
AI is rapidly evolving and still "new" by any stretch. The gap between a learner and teacher is still relatively small. My best advice for anyone wanting to use AI for marketing, product, or sales: just give it a shot, learn through experimentation and collaboration, and refine your process over time. There are no shortcuts on a path that has yet to be created.
Understand what AI learned from
We still need engineers who actually know how to build things. A model trained on developer forums and public repositories is learning from a skewed dataset: roughly 50% broken code with issues, 50% solved problems. The really good stuff: working, secure, scalable, well-architected production systems - almost never exposes its source code publicly. AI learns from visible debris of software development, instead of the invisible foundations that the best software operates on today. If you don't understand what the AI learned from, you can't predict where it will fail you. Rather than replacing engineers, I believe the future will be led by skilled engineers who understand both the systems being built as well as the AI's blindspots. These engineers become 10x more valuable, and the speed of software and product development will skyrocket.
Embodied context is the next frontier
We often talk about the need for more data in AI development, but overlook the need for humanity and context from the real world to guide it properly. We often assume "digital context" equals full context, but Internet-only data is noisy: keyboard warriors, sarcasm, and the echo chambers of social media can only tell AI about Uncle Frank's political leanings and religious preferences, not the facts and systems needed to build true intelligence. When AI observes not just text, but how humans act, move, and interact in physical space, it gains materially richer context. Wearables, AR glasses, robotics, and handheld devices capture motion, gesture, and environment (instead of just keyboard inputs).
The AI Box Model
Think about how we started - with AI in a chat window. That chat modality is "AI in the box": limited reach to external systems and trained on irrelevant data from non-applicable domains, constrained to simple question-and-response patterns. Then we connect the boxes - an LLM linked to a CAD system via MCP server, or a simulation engine that doesn't just answer questions but actually acts on your behalf. Finally, we move to "out of the box": AI everywhere, with connected systems and platforms generating the specific context you need. Vertical training creates specialist-level outputs versus the generalist responses you'd get from search.
The Antagonist agent
Many of today's AI coding assistants have a fundamental flaw: They treat almost every interaction as an isolated request, driving context rot and mistakes that might never happen through a human perspective. Rather than using a single AI agent, I orchestrate teams of specialized agents with persistent memory and adversarial quality control. The most critical innovation is the Antagonist agent: one specifically tuned to never provide positive reinforcement, and trained on the shortcomings of its own process. It identifies vulnerabilities, questions assumptions, and refuses to acknowledge progress until issues are resolved. This inverts the typical AI tendency toward affirmation and creates a forcing function for quality. If AI systems perform better with formalized adversarial roles, perhaps we should reconsider how we treat critical evaluation in our own processes.
Multi-agent orchestration in practice
Below is a screen capture of four Windsurf AI coding agents working simultaneously on different git worktrees for the same codebase. A fifth window (not shown) serves as the orchestration layer, directing tasks, resolving conflicts, and ensuring coherent progress across all workstreams. This is how I actually build.
Four AI agents working in parallel across git worktrees, orchestrated by a fifth
Making agentic AI accessible
I've always believed that the promise of AI is its ability to elevate our own capabilities and improve us societally. But for many, this technology remains locked behind a wall of complexity. My goal is to make agentic AI workflows accessible to everyone, regardless of technical background - teaching the principles of automation, not just a single tool.
Never copy/paste - always refine
I am strongly against copy/pasted AI output. It must be refined, nurtured, and verified. Context and data must be appropriate to ensure factually and directionally correct outputs. We must be mindful of blind spots that actually hinder us - both the AI's limitations and our own tendency to over-rely on its outputs without critical evaluation.

An infographic I created with GPT Image 1.5 exploring contrarian views on AI in academia
AI Should Be Fun
The joy in AI
In between working on AI content, building AI-powered software systems, and researching AI, we've got to recognize its power to have a little fun, right? I used Google's Nano Banana Pro to visualize my career journey as a 16-bit adventure map, because sometimes the best way to appreciate how far you've come is to step back and see it through a different lens.
Multi-model approaches win
Today's AI models are becoming better and better at research and discovery. But if you're looking for better results, I implore you to try a multi-agent system with a multi-model approach. The old adage "garbage in, garbage out" still applies, but with multiple models cross-checking each other, you're far less likely to let garbage through.
AI as the great equalizer
The potential for AI to reduce technical barriers for new founders is real. Low-cost experimentation is readily available, but it takes support from community, industry, and government to nurture small startups into high-powered companies. AI could be the great equalizer if we fund the bridge.
Sharing the journey
I share my experiments, wins, failures, and learnings from my research in Human-Computer Interaction and Artificial Intelligence as I go. The best way to learn is to build in public.

My career journey visualized with Google's Nano Banana Pro - Super Mario World style
What I'm Building
Making Dinosaur Videos for My Daughter
My favorite use case for AI is making "fun fact" dinosaur videos for my 4-year-old daughter. You know your kids best. I know mine loves dinosaurs - so I decided to surprise her.
Here's what I did (in less than 10 minutes):
- ChatGPT"Tell me a fun but little-known dinosaur fact for a 4-year-old"
- Veo 3.1Google's AI video model generates realistic dinosaur clips
- ElevenLabsSubtle background music to set the mood
- Adobe PremiereBring it all together with my own voiceover

Generated with Nano Banana Pro
The Recipe
"Hi baby, it's dada! Want to know a fun fact about the Triceratops?" + realistic dino clip + fun fact + another clip + horrible dad joke + "I love you!"
She watches them on repeat, giggling the whole time. No studio. No budget. Just tools that didn't exist 2 years ago. AI will never replace parenting, but through personalization, can help parents take care of some of their to-do list noise.
Ember - A Multi-Agent System for Professionals
Ember is something I built on my own, using Windsurf, Claude Code, and Google Antigravity. This tool deploys ADK/A2A, Claude Agent SDK, and models from OpenAI, Anthropic, and Google to achieve its mission - a multi-agent system for busy professionals who want to keep up with their networks.
It connects with over 30+ external services via API, MCP, and RSS to curate research and fact-check information in real-time. Built from the ground up with agentic architecture patterns.
Join Waitlist
My Toolchain
The tools behind the work above, and what each one is actually for.
Some of the links below are affiliate links, marked as such, so I may earn a commission if you sign up through one. Nothing here is a paid placement.
Windsurfaffiliate
Four agents on separate git worktrees, orchestrated by a fifth. The screen capture further up the page is an ordinary working session.
Terminal-side agent work: refactors, test generation, and review passes against a persistent project context.
Perplexityaffiliate
First pass on research. It hands back sources I can open and verify myself.
Railwayaffiliate
Deploy target for services and background workers once a prototype has outgrown a laptop.
Replitaffiliate
Where an idea goes when I want it running and shareable the same hour.
ElevenLabsaffiliate
Voice and score. The dinosaur videos above use it for the background music under my own voiceover.
Meshyaffiliate and Hyper3Daffiliate
3D asset generation when a video needs a model that does not exist yet.
Also in regular use
- Models and research
- Gemini, ChatGPT, Claude, Google Vertex AI, NotebookLM
- Agentic development
- MCP, Google ADK, A2A Protocol, RAG, LangChain, Claude Agents SDK, Markdown
- Cloud and infrastructure
- GCP, Azure, Snowflake, Confluent, Supabase, Vercel
- Product and analytics
- Jobs To Be Done, Pendo, Qualtrics, Tableau, LaunchDarkly, Sentry, PostHog
- Software engineering
- Python, TypeScript, SQL, C#, GitHub Copilot, Visual Studio, PyCharm
- Content
- Adobe Premiere, Canva
Working together
If how I think about this is useful to you, these are the ways I put it to work.