Bast.ai
If an AI gives you the right answer,
how do you prove it?
I came to Bast after 25 years at IBM, where I’d spent the last part of my career making AI visible, legible, and responsible in the interface. At a seven-person startup, those ideas stopped being guidelines for other teams. They became product requirements I had to carry into working software.
The chatbot sat at the visible edge of a much larger system. Making AI usable in a university, hospital, research center, or public library meant building the controls around every answer: which knowledge was in scope, who could change it, what behavior had been tested, how a deployment was approved, and where a user could inspect the evidence. My job was to turn that trust thesis into a product, and make sure a team our size could actually ship and operate it.
What Bast is
Bast is middleware 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 called CATs (conversational assistive technology). Each CAT combines a purpose, a set of behaviors, approved knowledge, specialized agents, and a visual theme. Knowledge owners 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 intent.
The bottleneck was 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.
Make trust operational
I drove the productization of Bast so customers could run the system themselves. The test was simple: could a 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 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:
- Customer-operated product. The customer runs the system; Bast supplies the product and its boundaries.
- Proof before production. Sources, tests, approvals, and version history exist before an answer reaches a user.
- Human authority stays visible. The system shows where people reviewed, approved, corrected, or refused what the automation proposed.
The chat was the smallest part of the product
The real product is the loop around the answer. Each response draws its credibility from everything that happens before it reaches the chat and everything the institution can inspect afterward.
- Create an organization with its own environment and access controls.
- Upload institutional knowledge and let the system propose a topic structure.
- Pause for a subject-matter expert to review that structure before processing continues.
- Configure a CAT: its purpose, behavior, knowledge, agent pool, and appearance.
- Test it against known questions, source requirements, and refusal behavior.
- Publish a versioned deployment with approval, activity history, and rollback.
- 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 makes readiness explicit. Basics, behavior, knowledge, agents, and appearance are separate, inspectable parts of one deployable system, with a five-part readiness model showing what still needs attention. The knowledge pipeline includes a deliberate human checkpoint before the proposed structure can move forward.
Publishing creates a version and preserves the history. Analytics connects real use back to the people who own the content by turning unanswered questions into a work queue. That link between use and upkeep carries the product from initial configuration into continuous operation.
The unanswered-question record matters more than it first appeared. Each gap shows where the institution’s source material, structure, or rules need work. The product gives uncertainty somewhere useful to go and surfaces what was often the most operationally valuable data the institution had never had.
The interface had to show its work, too
We designed evidence into the platform. Every important object has a visible state: draft, ready, published, disabled, awaiting confirmation, failed. Long-running work shows progress and recovery actions, while each deployment shows what version is live, who published it, and how to roll it back. The interface makes the system’s condition legible before someone acts on it.
Provenance sits beside the answer. A user can see the source material supporting a response and follow the system’s operations in language they can inspect. When the system retrieves a document, compares sources, applies a policy, or refuses a request, the interface describes 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 protects trust.
Different people enter the product at different altitudes. Executives need a readable view of readiness and risk. Operators need workflows, status, and recovery, while specialists need access to the underlying controls. Progressive disclosure serves all three in one connected product and gives each person a level of detail they can 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 functions as product infrastructure. It keeps status, hierarchy, accessibility, and feedback consistent as the product surface expands, and it gives every new workflow a tested visual grammar to start from.
We followed four design principles for everything we built:
Onboarding is the product
Guide users to create their first CAT right away, rather than showing everything at once.
Provenance is in the interface
When users see how an answer was created, that’s when they start to trust the system.
Everything shows its status
Every important element has a label, dot, or progress indicator. There are no anonymous loading spinners.
Simplicity over flexibility
Features that no one uses just create confusion for everyone. Any extra options need to prove their value through real use.
There was no one to hand it to
Bast was seven people. Beth Rudden carries the company direction and customer relationships. Thanh Lam led the core technical architecture. My accountability spanned 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 (now called BastCare) from a product brief to a working native iOS prototype in eight days, even though I’d never built an iOS app 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.
From a trust thesis to an operating product
By spring 2026, Bast’s materials recorded two live deployments and two 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, and MSU Denver completed a student-advisor pilot. 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, and student services 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.
What I carried out of 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 from this experience is that I’m not just a designer, engineer, or product person anymore. I’ve 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 even 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 this transition is its own piece. It’s called Know Yourself First, and I wrote it to explore what I’m becoming.