Career reflection and case study
Ellis AI: a career's worth of judgment, applied at home.
A private, self-hosted AI platform for my household — and the decade of enterprise and infrastructure work that shaped how I built it.
01 Why Ellis AI Exists
Could one system genuinely help my family, without treating every user the same way?
Ellis AI began as a practical question: could I build one private system that genuinely helped my family, without treating every user, conversation, and decision as if it carried the same risk?
The answer turned out to be more complicated than the question.
An executive assistant needs speed and broad latitude. A household assistant needs consistency more than cleverness. A tutor working with a child needs materially stronger safety boundaries than either of those. A financial assistant needs to be conservative by default, with a human reviewing anything that matters. A single generic assistant, built to be good at everything, is well suited to none of them — and dangerous in at least one.
One platform can serve multiple people only if it does not treat every user, conversation, capability, and action as carrying the same risk.
I didn't arrive at that idea through AI research. It came from a career spent inside enterprise systems — corporate transitions, platform ownership, automation, critical infrastructure, and the operational controls that keep all of it honest. Ellis AI grew from real use, not from a complete architecture I designed on a whiteboard in advance. What follows is less a description of what I built than an account of why building it felt familiar.
02 The Career Experiences That Shaped the Platform
Six lessons, learned long before there was a platform to apply them to.
Map dependencies before you change the system
Early in my career, working in enterprise technology supporting corporate divestitures, my job was to trace how a business was connected to the applications and systems around it, so it could be separated without breaking something no one had accounted for.
The lasting lesson: a system is rarely what it appears to be on the surface. Before you remove, replace, or isolate anything, you have to know what depends on it and what it depends on.
In Ellis AI, that instinct shows up as assistant boundaries, shared-service design, memory separation, and a habit of asking what breaks downstream before a change ships.
Ownership extends past keeping the lights on
Later, I owned enterprise software platforms used across a global organization — availability, recurring third-party risk reviews, vendor relationships, sourcing conversations, service-level performance, and the platform's own roadmap.
Ownership, I learned, includes controls, vendors, contracts, and long-term maintainability — not just whatever feature is shipping this sprint.
In Ellis AI, that means the platform gets the same treatment: external services are reviewed before they're trusted, model and vendor tradeoffs are made deliberately, and the system's health is something I monitor, not something I assume.
Automation changes the operating model, not just the workload
Supporting one of those platforms once required a sizeable team. I designed an automation that was later rebuilt into a more durable engineering solution; the support model that resulted needed a fraction of the original team, with one specialist retained to work alongside me.
The lesson wasn't "automation saves time." It was that real automation changes roles, staffing, and how work is organized — which means it deserves the same scrutiny as any other structural decision, not just credit as an efficiency win.
In Ellis AI, automation is judged by its consequences, not its convenience: human approval stays wherever judgment matters, and removing repetitive work is never allowed to quietly remove accountability with it.
Critical systems need resilience you can point to
My current work sits in critical financial infrastructure, leading delivery across multiple product areas — operational resiliency, backend and data delivery, efficiency initiatives, partnerships with quantitative and risk teams, and modernization of legacy systems. I'm not the deepest subject-matter expert in every one of those areas; my job is leading delivery through them, with the people who are.
What stays with me is the discipline: in an environment where reliability and recovery matter, you don't get to assume a release is fine because it compiled.
In Ellis AI, that becomes health-checked deployment, automatic rollback, backups before anything state-changing happens, and a plain assumption that any given release might be wrong.
Governance should improve decisions, not just document them
I keep getting pulled toward the same kind of problem: unclear ownership, poor handoffs, governance that exists on paper but doesn't actually help anyone decide anything. Teams ask me to help find a clearer path when engineering, operations, risk, and executives aren't lined up.
Governance is only useful if it answers concrete questions: who decides, who approves, what evidence is required, what happens when something fails, what's reversible, and what can't be delegated.
In Ellis AI, that's approval-gated command execution, autonomy granted in tiers, and a decision log that can't be quietly edited after the fact — governance built into the product, not bolted onto it afterward.
New technology earns trust through evidence, not demonstrations
Early exposure to enterprise automation taught me the gap between a vendor pitch, a demo, and something that holds up in production. Today, I contribute to evaluating AI-assisted tools being considered for broader adoption in my organization — as one voice in that effort, not as the person who single-handedly drove it.
The lesson: a capability isn't mature because it's impressive in a controlled setting.
In Ellis AI, new capability is introduced and watched first in the lowest-risk assistant, then hardened before it's trusted anywhere the cost of being wrong is higher — and nothing gets called finished before there's operational evidence it works.
03 What Ellis AI Became
One platform, four users, no room to get their boundaries wrong.
Ellis AI is a private, self-hosted, multi-user AI platform, designed around differentiated users, explicit trust boundaries, constrained computing resources, and human-controlled action.
| Assistant | Purpose | Primary design posture |
|---|---|---|
| Sloan | Executive assistance, research, planning, chief-of-staff support | Velocity and experimentation |
| Artie | Household operations and meal planning | Stability and consistency |
| Eunoia | Tutoring and creativity for a child user | Safety and age-appropriate interaction |
| Ellis | Household financial analysis and planning | Conservatism and human review |
New capability is introduced and observed in Sloan first — the lowest-stakes assistant — and only hardened into the others once it's earned the trust.
At an executive level, the platform includes local and external language-model routing, scoped memory per user, voice interaction, native mobile access, tool use governed by a privacy classifier, approval-gated command execution, health-checked deployment with automated rollback, service monitoring, and backups — with permission and safety models that differ deliberately by assistant. I designed, directed, integrated, and continue to operate the platform, using AI-assisted development where it made sense; the point was never to hand-write every line, it was to make the right calls about what the system should and shouldn't be allowed to do.
04 The Decisions That Define the Product
Five calls, each one a tradeoff, not a feature.
Boundaries by default; sharing by exception
Different users and trust levels need scoped memory, permissions, and context — the same instinct that made dependency mapping during a divestiture matter: know what's connected to what before you assume it's safe to share.
Autonomy is earned in tiers
Read-only diagnostics run freely. Routine, reversible actions run with light oversight. Anything that changes real state needs approval. And a category of action was left deliberately unbuilt, because its control model wasn't mature enough yet. Capability alone doesn't justify authority.
Every release assumes it might be wrong
Validate, test, back up, deploy, health-check, and roll back automatically if the check fails — plus one deliberately low-tech kill switch. That posture isn't abstract; it's the same one critical financial infrastructure requires of any change to a system where reliability matters.
Privacy can outweigh capability
An external service may perform better on a given task, but performance isn't the only criterion. Some information stays local by design, and when sensitivity is unclear, the system defaults toward less exposure, not more.
Measure the bottleneck before you optimize it
The assumed problem with voice interaction was model quality or model speed. The actual delay was a one-time initialization cost paid by whoever spoke first. The fix wasn't a better model — it was paying that cost in advance. The most visible problem is not always the real constraint, in a system or in a team.
05 When the Platform Failed
Failure & tradeoffIts failures had to become operational failures, not something to shrug off as "the model being a model."
A targeted review of recent conversations found fabricated factual claims running through the large majority of them — invented sources, fabricated data presented as retrieved, even the platform's own underlying technology described using vocabulary borrowed from an unrelated industry. The sample was small and the review was deliberately targeted, not a random audit — but it was enough to establish that the failure was systemic, not an edge case.
Five unrelated causes, not one
Tracing the fabrications back to their actual causes turned up five distinct, unrelated root causes:
- 1
Contamination from unrelated system vocabulary leaking into prompts.
- 2
A retrieval fallback that wasn't triggering for an entire category of questions.
- 3
A phrasing instruction that degraded into a repetitive, fabrication-prone pattern under pressure.
- 4
A voice-transcription error treated as a reliable premise.
- 5
A request type silently misrouted to the wrong capability.
None of the five would have been caught by fixing any of the other four. Stopping at the first plausible cause — the obvious one — would have reduced the error rate and left the system unreliable, with no framework for explaining why.
The response addressed all five together: better context isolation, a corrected retrieval fallback, revised prompting, stronger handling of uncertain transcription, and clearer abstention when the system doesn't actually have grounding for an answer.
A code fix is not proof of correct behavior under real, unscripted use, and I'm not interested in claiming more certainty than the evidence supports.
06 Reflection
What the build revealed about my career.
Building and operating Ellis AI didn't teach me a new way to work. It made an existing pattern harder to miss.
Systems thinking. I look for dependencies, interactions, and failure paths before I look for the isolated task — a habit formed early, tracing what a corporate transition would break, long before it showed up in a platform design.
An instinct toward the inefficiency. Unnecessary complexity, manual work, unclear ownership, and governance friction tend to find me. My default response is to understand the cause and redesign the operating model, not tolerate the workaround.
Fast, honest domain acquisition. Corporate technology transitions, enterprise platforms, risk and quantitative initiatives, critical financial infrastructure, AI systems — I've taken ownership of unfamiliar territory repeatedly, learned enough to make responsible decisions, and stayed honest about not being the deepest specialist in the room.
Translation across disciplines. I work between executives, engineers, operations, risk, quantitative teams, vendors, and end users. Much of the value I add is converting different kinds of expertise into one plan the whole group can act on.
Governance as a design discipline, not paperwork. Permissions, approvals, evidence, escalation, and recovery are part of the product, decided at the same table as the features — not appended afterward by someone else.
Leadership that doesn't depend on hierarchy. Most of my career has involved coordinating people who don't report to me. What that requires is clarity, credibility, a decision structure everyone can see, and a willingness to own the part of the problem no one else wants.
Technical fluency in service of leadership, not instead of it. I'm not positioning myself as a specialist engineer. I can reason credibly about architecture, data, deployment, failure handling, and operational tradeoffs — enough to lead technical work well past backlog administration.
Comfort naming limitations. I distinguish ownership from authorship, domain experience from deep expertise, a code change from runtime proof, and a pilot from a finished rollout. I'd rather leave a capability unbuilt than pretend its controls are ready.
The pattern isn't that I've collected a series of unrelated technical experiences. It's that I keep landing near systems that are complex, inefficient, or poorly understood, and I've built the habits to make them more coherent. Ellis AI is the most complete expression of that pattern, because it asked for all of it at once — product judgment, architecture, governance, privacy, resilience, prioritization, and the discipline to keep learning after the interesting part was done.
What is still unfinished
The recent fabrication fixes still need long-term validation under real use, not just a clean diff. Behavior under more users and higher concurrency is untested.
- Assistant quality doesn't yet have a formal measurement over time, and child-safety behavior in particular deserves a harder look than it's had.
- Security review has room to go further, and recovery objectives could be more precise.
- Any expansion of action-taking capability needs to stay controlled and deliberate, not incremental by default.
- Whether any part of this should become public or reusable — and whether Ellis AI stays a personal platform, becomes a portfolio asset, or eventually informs something built for more than one household — is still an open question.
None of that is a weakness to manage around. Knowing which claims haven't been earned yet is part of the same judgment the rest of this reflects.
Closing reflection
Ellis AI didn't teach me an entirely new way to work. It made visible the way I had already learned to work.
The same instincts that shaped the platform were built through corporate transitions, enterprise platform ownership, automation, vendor governance, critical infrastructure, and product delivery: understand the dependencies, make boundaries explicit, automate carefully, design for failure, and don't declare success before the evidence exists.
The platform is still evolving. So is my read on what it should become. But it's clarified the kind of work I'm best at — taking an ambiguous, consequential system, learning how it actually behaves, and building a more coherent way forward.
Ellis AI isn't separate from my career story. It's where the lessons of that career became one operating system.