Bast.ai

Bast is software that lets an institution control what AI says on its behalf. It sits between the institution’s approved knowledge and the language model that generates a response. Before an answer reaches a user, Bast retrieves from approved sources, applies the institution’s structure and policies, and preserves a trail back to the material that supported it.

An organization uses Bast to create, configure, and deploy conversational assistants, which we call CATs. Each CAT combines a purpose, a set of behaviors, approved knowledge, specialized agents, and a visual theme. The people who own the knowledge can upload source material, review how it’s organized, decide what the CAT can use, test its responses, and publish it through the same product.

The end user receives an answer with evidence they can inspect. The institution sees what people are asking, which questions have verified answers, and where the available knowledge runs out. Bast turns those gaps into work for the people responsible for the content, so the system improves through explicit human attention and approval.

The models were already impressive. The product still lacked the evidence and control required for approval. Once an answer entered a university or hospital, it created a chain of accountability the model couldn’t satisfy by itself: an executive had to approve the system, a domain expert had to stand behind its knowledge, and a student, clinician, patient, or researcher had to decide whether the answer was safe to use.

That chain created three distinct product audiences. Each needed a different view of the same underlying evidence.

The approver needed to see the boundaries: what the system could answer, where it stopped, what had changed, and who had approved it. They needed a risk and activity story they could explain in a board meeting.

The knowledge owner needed control of the source material and the structure around it. They needed to review what the system proposed, update their knowledge directly, and see where real questions exposed gaps.

The person asking needed the receipt: the document, the relevant source, and a clear signal when the evidence ran out. The answer had to help them verify the claim for themselves.

Most enterprise AI products treated those needs as reports, logs, or governance added after the fact. That was exactly where we disagreed. Trust had to live in the runtime and the interface, ready before a failure ever happened.

I drove the productization of Bast so customers could run the system themselves. The test was simple: could a sophisticated customer deploy Bast using the product, documentation, and their own subject-matter experts? That test changed both the scope and shape of what we built.

The executive experience became a first-class view of readiness, policy, risk, and activity in plain language. It had to translate the system’s state into something an accountable leader could understand and act on. The product had to build confidence through what it revealed, how clearly it revealed it, and what actions remained under human control.

At the point where human judgment mattered, the knowledge workflow stopped, showed the proposed topic structure, and waited for the owner’s review. Deployment then carried that same discipline into named states, approval gates, version history, and non-destructive rollback. Every stage had to make the next responsible action obvious.

The product strategy reduced to three rules:

1. Customer-operated product. The customer runs the system; Bast supplies the product and its boundaries.
2. Proof before production. Sources, tests, approvals, and version history exist before an answer reaches a user.
3. Human authority stays visible. The system shows where people reviewed, approved, corrected, or refused what the automation proposed.

The real product was the loop around the answer. Each response drew its credibility from everything that happened before it reached the chat and everything the institution could inspect afterward.

1. Create an organization with its own environment and access controls.
2. Upload institutional knowledge and let the system propose a topic structure.
3. Pause for a subject-matter expert to review that structure before processing continues.
4. Configure a CAT: its purpose, behavior, knowledge, agent pool, and appearance.
5. Test it against known questions, source requirements, and refusal behavior.
6. Publish a versioned deployment with approval, activity history, and rollback.
7. Watch what people ask, where verified answers exist, and where the system reports an evidence gap, then improve the knowledge and run the loop again.

The CAT workspace made readiness explicit. Basics, behavior, knowledge, agents, and appearance were separate, inspectable parts of one deployable system, with a five-part readiness model showing what still needed attention. The knowledge pipeline included a deliberate human checkpoint before the proposed structure could move forward.

Publishing created a version and preserved the history. Analytics connected real use back to the people who owned the content by turning unanswered questions into a work queue. That link between use and upkeep carried the product from initial configuration into continuous operation.

The unanswered-question record mattered more than it first appeared. Each gap showed where the institution’s source material, structure, or rules needed work. The product gave uncertainty somewhere useful to go and surfaced what was often the most operationally valuable data the institution had never had.

I designed evidence into the platform. Every important object had a visible state: draft, ready, published, disabled, awaiting confirmation, failed. Long-running work showed progress and recovery actions, while each deployment showed what version was live, who published it, and how to roll it back. The interface made the condition of the system legible before someone acted on it.

Provenance sat beside the answer. A user could see the source material supporting a response and follow the system’s operations in language they could inspect. When the system retrieved a document, compared sources, applied a policy, or refused a request, the interface described what happened in concrete terms.

We banned anthropomorphic language early. In the interface, the system retrieved, collated, compared, checked, ranked, and returned. Words like “think” and “understand” blur operations into simulated judgment, so they stayed out. That copy choice protected trust.

Different people entered the product at different altitudes. Executives needed a readable view of readiness and risk. Operators needed workflows, status, and recovery, while specialists needed access to the underlying controls. Progressive disclosure served all three in one connected product and gave each person a level of detail they could act on.

Under those screens, I built a shared visual system of tokens and reusable components for the admin console, chat, patient experience, and internal design-system environment. The design system functioned as product infrastructure. It kept status, hierarchy, accessibility, and feedback consistent as the product surface expanded, and it gave every new workflow a tested visual grammar to start from.

We followed four design principles for everything we built:

Bast was seven people. Beth Rudden carried the company direction and customer relationships. Thanh Lam led the core technical architecture. My accountable surface ran from product strategy and positioning through interaction design, the shared design system, the front end, and, when the team needed it, working code.

That breadth shortened the feedback loop. A product decision could become a screen, meet the architecture, fail a test, and come back as a better product decision inside one continuous working loop. Interface decisions exposed missing states; architecture constraints sharpened the workflow; working code forced the product language to become precise.

I worked spec-first and used AI throughout the delivery process. Evidence defined done: the behavior had to run, the state had to be inspectable, and the change had to survive review. That discipline increased velocity: in one measured month, we closed roughly 60 tracked changes against a plan of 17.

Later, the company needed to test a narrower consumer direction. I took CareLoops from a product brief to a working native iOS prototype in twelve days, even though I’d never built for iOS before. The build showed the new pace, and its guardrails carried the trust principles forward: consent before every recording, patient-controlled sharing, source attribution, and a transcript designed to disappear after the visit summary was created.

The prototype turned a doctor’s visit into something a patient could understand and, if they chose, share with the people caring for them. Its central idea lived in one sentence telling the patient exactly who could see the version they’d approved. That moment made control visible in the language and flow of the product.

By spring 2026, Bast’s materials recorded two live deployments and three completed pilots. At Maryville University, social learning companions were associated with lower nursing-student attrition and avoided cost. At Northwestern Medicine/Lurie Cancer Center, researchers could query instrument and assay knowledge with source traceability.

Craig Hospital completed a caregiver-support pilot for neurological recovery. MSU Denver completed a student-advisor pilot, and Simwerx deployed an offline medical copilot through a versioned registry. Each deployment stressed a different part of the product model, and together they showed that approved knowledge could move into education, clinical research, caregiver support, student services, and a disconnected environment while preserving the source trail and the institution’s control.

The product changed what Bast asked a customer to believe. Trust now had somewhere concrete to live: the reviewed knowledge, the configuration, the readiness state, the test evidence, the deployment history, the answer, and the source behind it. We’d moved the conversation from trust us to inspect it.

At IBM, my job often involved keeping intent intact across a very large system. At Bast, the distances collapsed. Strategy, product, interface, and implementation were close enough that I could feel exactly where the intent held and where it leaked.

The experience changed my definition of design because I became continuously responsible for the product’s meaning across strategy, interface, and code. A small team removes handoffs through that kind of ownership. Each discipline stays distinct, while the same intent travels through all of them. That was the work.

Coda

In the summer of 2026, I finished this chapter and moved on to the next while Bast continues. What I took with me is the answer to the question this case opens with: I’m not just a designer, engineer, or product person anymore. I have continued to lead through uncertainty, to build trust not just in systems but in people, and to adapt quickly to new challenges. The transition forced me to become more comfortable making decisions with incomplete information, to prioritize what matters most, and to let go of old definitions of my role so I could grow into a more versatile leader. The role didn’t disappear. It grew into something only one person can truly define, and carrying that meaning became the real job.

The long version of that answer is its own piece. It’s called Know Yourself First, and I wrote it to find out what I’ve become.