Context is infrastructure.
Give an agent the relevant goals, history, constraints, and organizational knowledge at the moment of work. Preserve durable records; select what belongs in the current context.
In practice: cllamaFounder · Developer · Systems thinker
At the interface of
people & software.
I design systems around the work people actually do. From publishing and clinical workflows to AI agents, the challenge is making powerful technology useful, understandable, and dependable.
How I think about AI01 / The approach
Intelligence needs an environment.
An agent doesn’t naturally know your organization, remember its obligations, or have the authority to act. Those capabilities need to be designed—and so does the relationship with the people who depend on it.
Give an agent the relevant goals, history, constraints, and organizational knowledge at the moment of work. Preserve durable records; select what belongs in the current context.
In practice: cllamaUseful tools, clear identities, scoped permissions, memory, and observable results. Make capabilities discoverable and boundaries explicit instead of expecting a prompt to do everything.
In practice: ClawdapusSpecialists can work independently without losing the shared goal. Define ownership, handoffs, and review. Keep the state of the work outside any one conversation or agent.
In practice: Talking StickModels, processes, and networks fail. Build bounded retries, fallback paths, checkpoints, and recovery. Use redundancy and independent review deliberately; don’t confuse repetition with assurance.
In practice: Gnit & durable workflowsApproval is an interface, not a checkbox. Show the right evidence, bind a decision to the work being reviewed, and make it possible to question, correct, pause, or resume.
In practice: supervised supportA system succeeds when people can work with it. Teach through real tasks, explain the limits, make onboarding repeatable, and let feedback from daily use change the design.
In practice: My AI at Flux02 / A connected body of work
Selected milestones · 1995–2026
How do you turn a complicated process into something people can actually use? That question connects my work in enterprise systems, medical imaging, product development, and AI.
1995–2004 Foundations
Early work at Hess Packaging and Aymes Medical brought databases, reporting, deployment, and support into direct contact with business and clinical needs.
The process matters as much as the program.
Hess Packaging (1995–1996) and Aymes Medical (1995–2004) established a practical foundation: understand the existing workflow, make the software fit, and support the people using it. Later research-computing work at the University of Toronto added experience with imaging, experimental systems, and scientific infrastructure.
Databases / Medical reporting / Deployment / User support
2007 Company & product building
As founder of Flux, I brought together software development, product decisions, sales, integration, and support. DICOM Printer was already being sold and integrated into imaging workflows in 2007.
A product includes its path into use.
Medical software has to fit into an existing environment of equipment, systems, roles, and habits. Product work meant understanding those dependencies, demonstrating the value, coordinating implementation, and staying involved after delivery.
Product leadership / DICOM / Partner integration / Commercialization
2009–2013 Enterprise & production workflows
Video production, publishing, marketing, and enterprise software exposed another side of the same challenge: coordinating intake, people, production capacity, quality checks, and delivery. Influx work connected technical product development with sales and implementation.
A workflow is a human–software interface.
The useful unit of design is the whole process: who receives a request, what information is missing, where decisions happen, how work changes hands, and how quality is established. Production workflow work included change control, training, and operational coordination—not just feature development.
Process design / Publishing & marketing / QA / Enterprise implementation
2013–2017 Products & platforms
Hands-on Rails development for DXA reporting, content platforms, and commerce; pharmacy integration architecture; and product ownership for consumer information tools. Different domains, each requiring a usable end-to-end process.
Architecture has to account for the handoff.
Ruby / Rails / APIs / Data modeling / Rollout design
2018–2024 Systems that have to keep working
Substantial C# work on DICOM Capacitor, C++ work on DICOM Printer 2, interactive workflow development, and continued medical-software delivery. AI-assisted coding was part of my own workflow by 2024.
Success is more than a successful request.
Imaging and clinical integration bring services, queues, destinations, and operators into one chain. A process starting, a message arriving, and a customer completing the intended workflow are different kinds of evidence. That distinction also shapes how I approach agent systems.
Other work included Ruby/Vue/JavaScript implementation for conversational and conversion workflows, and Rails marketplace-domain development.
C# / .NET / C++ / Qt / JavaScript / Vue / Operational reliability
2025 Context, tools & governance
A DICOM MCP prototype connected AI tooling to an established technical domain. With the Flux team, I explored RAG, organizational knowledge, role-aware context, memory, and conversational governance.
Don’t just prompt the model. Design its environment.
Python / MCP / RAG / Context engineering / Governance architecture
2026 Infrastructure & adoption
Clawdapus, cllama, My AI, Talking Stick, and Gnit address complementary needs: deployment, governed inference, organizational context, collaboration, and coordinated change. At Flux, the work extends to onboarding, supervised support, and AI-assisted software delivery.
Build the system. Teach it. Put it to work.
I create and maintain these tools using AI-assisted development. The goal is not one all-purpose agent: it is a coherent environment where different agents and people can work with appropriate context, explicit responsibility, and a recoverable record of progress.
Further work on durable human–agent orchestration explores tasks, questions, independent review, and recovery through development pilots.
Go / Rust / TypeScript / Agent infrastructure / Organizational adoption
Selected project milestones, not exclusive employment periods. Much of this work overlaps.
03 / The tools behind the thinking
Original projects · AI-assisted development
Practical tools for the gaps between a capable model and a dependable way of working.
Declarative agent infrastructure: compile contracts, runtime configuration, tools, and context into containerized environments around existing agent runtimes.
Go · DockerA model gateway with runtime context, memory hooks, provider adaptation, managed tool execution, usage accounting, and policy integration points.
Go · MCPBring company context, skills, tools, and policy into human–agent workspaces. Make onboarding repeatable and publication an explicit, governed step.
Go · CLIShared-workspace coordination for people and coding agents: writer ownership, leases, messages, and handoffs. A cooperation protocol, not a filesystem sandbox.
TypeScript · SQLiteCoordinate changes across independent Git repositories with explicit pins, branch-aware checkouts, and ordered publication that respects existing work.
Rust · Git04 / People make it work
Advocacy, teaching, and mentorship are part of my technical practice. I want people to understand a system well enough to use it, question it, and help make it better.
At Flux, I demonstrate tools in working sessions, help staff adopt shared AI workspaces, and turn company knowledge into reusable context and skills. Onboarding friction is design feedback.
Supervised support work at Flux has exercised agent drafting, human approval of an exact revision, and controlled delivery. The useful outcome is a reviewable workflow—not merely generated text.
I work across discovery, architecture, implementation, sales, and support. That breadth helps me find where automation belongs, explain its value, and design a path from a promising demonstration to everyday use.