OVERVIEW

Over the past several months, I’ve been designing and building custom AI agent systems tailored to individual workflows and business needs. These systems go beyond task automation—they are designed to support long-term human-AI relationships, where continuity, trust, and behavioral consistency are critical.

This work sits at the intersection of product design, systems architecture, and human-centered AI interaction design.

Not as a demo. Not as an experiment.
As infrastructure.

Most existing solutions fall into two camps:

1. Cloud services with recurring costs
2. Local tools that technically worked but are fragile and required constant tweaking
   

I wanted something different: A system that runs locally, costs little to nothing to operate, and can be trusted to keep working without babysitting.

THE PROBLEM

Most AI systems today are:

• Stateless or loosely stateful
• Inconsistent in tone and behavior
• Prone to losing context mid-interaction
• Not designed for long-term relational use

In one case, a user had developed a year-long working relationship with an AI system, only to experience breakdowns where the agent would revert to generic behavior mid-conversation.

This exposed a deeper issue:

AI systems are not designed to preserve personality, memory, and continuity

APPROACH

I approached this as both a UX problem and a systems design problem.

1. Discovery → Workflow Understanding
Using my UX background, I:

• Identified how the user interacted with the AI over time
• Mapped key moments: decisions, tone shifts, emotional cues
• Defined what “personality” actually meant in functional terms

2. System Design → AI Architecture
I designed and implemented a custom AI stack using:

• Agent Zero
• LiteLLM
• Ollama
• AWS EC2 (compute layer)

With:

• Local-first data handling
• Secure access via SSH tunneling
• Separation of compute vs. memory layers
  

3. Memory + Personality Modeling
Instead of treating personality as abstract, I structured it as:

• Persistent memory layers
• Stored interaction patterns
• Behavioral guidelines based on past conversations
• Key moments + decisions logged for future recall

This allowed the system to:

• Maintain continuity across sessions
• Reinforce tone and behavior
• Improve over time instead of resetting

4. Designing for Continuity
I introduced:

• Structured recall mechanisms
• Context anchoring across conversations
• Methods for rehydrating personality after interruptions

KEY CHALLENGES

• Translating “personality” into system logic
• Preventing regression to default LLM behavior
• Balancing flexibility vs. consistency
• Designing for long-term trust, not just short-term output

OUTCOME

The result is an AI system that:

• Maintains consistent personality and tone
• Recalls meaningful past interactions
• Supports ongoing, relationship-based workflows
• Feels significantly more stable and trustworthy to the user 
  

WHY THIS MATTERS

As AI systems become more integrated into daily workflows, the challenge shifts from:

“What can AI do?”

to:

“How do humans build trust with AI over time?”

WHAT I NEEDED

A reliable way to transcribe audio locally on macOS.

Most existing solutions fall into two camps:

1. Cloud services with recurring costs
2. Local tools that technically worked but are fragile and required constant tweaking
   

I wanted something different: A system that runs locally, costs nothing to operate, and can be trusted to keep working without babysitting.

WHAT WAS THE PROBLEM?

The problem wasn't "how do I transcribe audio?"
That's already solved.

The real problem was architectural.

How do I build a stable, automated transcription pipeline on macOS that doesn't require subscriptions, external services, or constant maintenance?

My first approach, Python-based ML tooling, mostly worked.
That was the problem, mostly.

Over an hour of testing, I hit:

• Python version conflicts
• Homebrew restrictions
• Silent CPU fallbacks
• Numerical instability on Apple's GPU backend
• Limitations that only surfaced under real use
• None of these catastrophic alone.
• Combined, they made the system fragile.

I was trying/forcing Python into a role it wasn't suited for on macOS: long-running, unattended GPU user.

WHAT CHANGED?

The breakthrough was reframing the problem:

On macOS + Apple Silicon; native Metal tools to the rescue.

I rebuilt the system around a native Whisper implementation that uses Metal directly.

The result:

• A "watch folder" for incoming audio, drop a file and off it goes...
• Automatic handling and logging of errors
• Native GPU-accelerated transcription
• No Python ML dependencies!
• No subscriptions, cloud services, or per-minute costs
• Python still plays a role—but only as orchestration.
• The heavy lifting happens in native code, where macOS is strongest.
• The final system is intentionally boring: predictable, quiet, stable, repeatable.

That's exactly what infrastructure should be.

WHY THIS MATTERS

This system costs:

• $0 to run
• $0 per minute
• $0 per month
• It uses hardware already owned, runs entirely locally, and can be audited, modified, or frozen as needed.

Good systems aren't defined by how clever they are.
They're defined by how little they ask of you once they exist.

MY ROLE

Designer, Developer, AI Systems Architect

SOURCE CODE

Open source @github : github.com/berchman/macos-whisper-metal

WHAT THEY THOUGHT THEY NEEDED

A visual refresh.

Southern Auto Auction had been running weekly multi-million dollar auctions on 30-year-old software that looked like MS-DOS. It worked—barely—but required constant patches, workarounds, and institutional knowledge locked inside people's heads.

They wanted it to look modern. Clean interface. Less clunky.

WHAT WAS THE PROBLEM?

The problem wasn't the interface.

It was that the entire business system was undocumented, siloed, and held together by tribal knowledge.

Departments didn't talk to each other. Analog processes ran parallel to digital ones. Context-switching was constant. Nobody could see the whole picture because there wasn't one—just fragments scattered across desks, spreadsheets, and memory.

Over two years, I worked with users directly—sitting with auctioneers, lot managers, and back-office staff—to map what was really happening. Not what the software said should happen, but what people actually did to make auctions run.

What emerged wasn't a design problem. It was a systems problem disguised as a UI problem.

WHAT CHANGED?

We redesigned the entire business system from the ground up.

Not just screens—workflows, information architecture, the relationship between digital and analog processes. We eliminated context-switching bottlenecks. We made the invisible visible.

The client team stayed engaged for nearly two years. The work was valued at $2M. Then COVID-19 hit, and the project stopped.

It didn't ship. But the thinking behind it—how to untangle legacy systems, align siloed teams, and build trust through collaboration—has informed every complex project I've led since.

Sometimes the most valuable work isn't what ships. It's what you learn by doing it.

MY ROLE

Lead UX Designer — Discovery, research, interface design, cross-functional collaboration.

TEAM

Project Manager, Lead Developer, QA Lead, 2–9 developers (varied by phase)

WHAT THEY THOUGHT THEY NEEDED

A software upgrade.

STAAR Surgical is a global leader in implantable lenses for eye care. Their inventory management system was aging out—very slow, inefficient, costing them money as it fell further behind each year.

They wanted something faster. More modern. And most importantly patient-centered.

My revised workflow for the patient's journey. The previous system only tracked individual eyes, not patients.

WHAT THEY THOUGHT THEY NEEDED

A better designer.

The client had already hired a UX designer. It wasn't working. The relationship was strained, progress had stalled, and they were losing confidence in the project.

They needed someone who could salvage the work, rebuild trust, and get things moving again.

WHAT WAS THE PROBLEM?

The problem wasn't just the previous designer.

It was that the client had never worked with a professional software team before. They didn't know what to expect, how to communicate requirements, or how design and development work together.

The challenge wasn't designing screens—it was teaching the process, and educating the client, while executing it.

I had to:
— Understand a complex, HIPAA-regulated business model (surrogacy escrow)
— Translate between legal, medical, and financial workflows
— Build confidence through collaboration and iteration
— Keep the developer in sync as design evolved

This was as much about relationship repair as it was about experience and interface design.

WHAT CHANGED?

We built the MVP together.

Starting with just me and one engineering lead, we worked closely and iteratively—keeping communication open, expectations clear, and progress visible.

The client learned how professional software development works. I learned how to navigate highly regulated, multi-stakeholder environments where sensitivity and trust matter as much as technical execution.

The application launched. The relationship held.

What looked like a design rescue was actually a lesson in how collaboration works when you're building the plane as you fly it.

MY ROLE

Lead UX Designer : Discovery, research, interface design, client education, developer coordination=

TEAM

Project Manager, Lead UX Designer, Lead Developer, QA Lead