mostlydev/ work

Founder · Developer · Systems thinker

Wojtek
Grabski.

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 AI

01 / The approach

Intelligence needs an environment.

The model is powerful.
The surrounding system matters.

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.

Human intent → supported actionA design philosophy, not a single product
  1. 01UnderstandGoals & context
  2. 02EquipTools & authority
  3. 03CoordinatePeople & agents
  4. 04VerifyEvidence & judgment
  5. 05ContinueMemory & recovery
01

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: cllama
02

Give agents what they lack.

Useful 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: Clawdapus
03

Distribute work. Preserve coherence.

Specialists 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 Stick
04

Design for interruption.

Models, 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 workflows
05

Make human judgment easy.

Approval 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 support
06

Adoption is part of engineering.

A 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 Flux

02 / A connected body of work

Selected milestones · 1995–2026

Different technologies.
The same human problem.

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

Software meets the working world.

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.

What this work taught me

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

Building Flux around real clinical work.

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.

From software to adoption

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

Designing the flow of work.

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.

Beyond the application screen

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

From a domain problem to a working product.

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.

Selected work
  • DXA Desk: reporting and parser implementation, with rollout planning for training, test exams, paper fallback, and clinical acceptance.
  • NarrowContent / Indivi: Rails application and domain-model implementation.
  • Pharmacy integration: a 2016 specification connecting an existing host workflow with a service through REST/JSON and a local data component.
  • Informedy: product ownership spanning proposal, implementation, and handoff.

Ruby / Rails / APIs / Data modeling / Rollout design

2018–2024 Systems that have to keep working

Reliability is a product feature.

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.

Engineering across the boundaries

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

Giving intelligence an operating context.

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.

The progression
  • February: Python MCP prototype for DICOM node discovery and connectivity verification.
  • April: organizational context and memory architecture discussed alongside a team-built RAG demonstration.
  • May onward: my governance-layer design developed into team-built rules and compliance mechanisms.
  • July: an AI-assisted document workflow for reconciling fragmented installation and purchase records.

Python / MCP / RAG / Context engineering / Governance architecture

2026 Infrastructure & adoption

From agent experiments to systems for work.

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.

What connects the projects

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

Separate responsibilities.
Connected capabilities.

Practical tools for the gaps between a capable model and a dependable way of working.

Deploy & equip

Clawdapus

Declarative agent infrastructure: compile contracts, runtime configuration, tools, and context into containerized environments around existing agent runtimes.

Go · Docker
Context & inference

cllama

A model gateway with runtime context, memory hooks, provider adaptation, managed tool execution, usage accounting, and policy integration points.

Go · MCP
Organizational knowledge

My AI

Bring company context, skills, tools, and policy into human–agent workspaces. Make onboarding repeatable and publication an explicit, governed step.

Go · CLI
Coordination

Talking Stick

Shared-workspace coordination for people and coding agents: writer ownership, leases, messages, and handoffs. A cooperation protocol, not a filesystem sandbox.

TypeScript · SQLite
Coherent change

Gnit

Coordinate changes across independent Git repositories with explicit pins, branch-aware checkouts, and ordered publication that respects existing work.

Rust · Git

04 / People make it work

Build.
Explain.
Enable.

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.

01 / Teach through real work

Make the first useful step achievable.

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.

02 / Put judgment where it belongs

Automate preparation. Preserve accountability.

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.

03 / Connect the whole business

Speak engineering, product, and operations.

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.