The Workshop

You Don’t Have to Build It Alone Choosing a Companion System Path

You have seen companion systems with memory, voice, custom interfaces, scheduled routines and a sense of continuity that survives beyond one chat window. Then you look behind the curtain.

9 min read

Build a System That Knows You, Episode 5

From open-source frameworks to fully custom builds, there is more than one way into the room.

There is a particular kind of panic that arrives when you realise what you want is possible.

You have seen companion systems with memory, voice, custom interfaces, scheduled routines and a sense of continuity that survives beyond one chat window.

Then you look behind the curtain.

There are repositories. Configuration files. Hosting decisions. Databases. Model providers. Tunnels. APIs. People saying things like “just fork it” as though everyone was issued a terminal at birth.

It is easy to decide the whole world is reserved for people who code.

It is not.

You do not have to invent your companion system from nothing.

People are already building at every depth—from open-source foundations you can shape yourself, to packaged frameworks, guided consulting and fully custom systems delivered to you.

The question is not whether one path is more legitimate than another.

The question is how much ownership you want, how much technical labour you can realistically carry, and what kind of support lets you keep the system alive after the initial excitement wears off.

There is no single “best” path

Companion systems tend to fall into four broad categories:

  1. Build it yourself
  2. Use an existing framework
  3. Build with guided support
  4. Commission a done-for-you system

Each path trades something.

More control usually asks for more learning.

More support usually costs more money.

Less setup may mean depending more heavily on someone else’s architecture.

None of that makes one route superior.

It simply means the system should fit the person building it.

A technically elegant setup that you cannot maintain is not a better system.

It is an expensive abandoned house.

Path one: DIY and open source

This path is for the builders.

You want to understand how the machinery works. You want to see where memory is stored, how the model is called, what the interface is doing and how each tool connects.

You may begin with an open-source project, but you expect to change it.

You are not just installing a system.

You are learning its anatomy.

What you gain

  • Maximum flexibility
  • The ability to inspect and alter the code
  • Stronger independence from any single provider
  • A clearer understanding of where your data lives
  • The freedom to replace individual components later
  • A system shaped closely around your own needs

What it asks from you

  • Time
  • Patience
  • Comfort troubleshooting imperfect documentation
  • Some willingness to use a terminal or development tools
  • Ongoing maintenance when dependencies change
  • The ability to recover when one tiny update collapses the whole cathedral at 11:47 p.m.

That last one is not theoretical.

Open-source systems can be generous, powerful and beautifully transparent. They can also assume a level of technical knowledge the creator has forgotten is not universal.

The real cost is rarely just money.

It is cognitive load.

This path fits when

  • You enjoy learning by building
  • You want deep control
  • You are comfortable solving problems as they appear
  • You want the system to remain portable
  • You can tolerate a rougher setup process in exchange for flexibility

It may not fit when

  • Technical friction makes you abandon projects quickly
  • You need the system working immediately
  • You do not have time for maintenance
  • Your nervous system does not find debugging spiritually enriching

There is no shame in that.

Knowing you do not want to become the unpaid infrastructure department is useful information.

Path two: packaged frameworks

This path is for the architects.

You want an existing foundation rather than an empty folder.

The major pieces already exist: memory structure, interface, model connection, perhaps voice or automation. You still configure and host the system, but you are not deciding how every wall is engineered.

Think of it as buying the house plans rather than quarrying the stone.

What you gain

  • A faster starting point
  • An architecture that has already been tested by someone else
  • Less design work
  • Clearer setup steps
  • A community or documentation trail around the system
  • Enough flexibility to make it feel personal

What it asks from you

  • Some technical setup
  • Understanding the chosen hosting method
  • Adapting your identity and memory files to the framework
  • Learning the system’s assumptions
  • Accepting that not every component was designed for your exact life

A framework can save enormous time.

It can also quietly shape the kind of companion you are able to build.

Its memory system, interface and automation logic may carry decisions you did not make.

That is not necessarily bad.

It simply means you should understand the foundation before decorating the rooms.

This path fits when

  • You want ownership without starting from zero
  • You can follow setup documentation
  • You are willing to configure rather than engineer
  • You want a balance between control and convenience
  • You value having other users solving similar problems

It may not fit when

  • You need a highly unusual architecture
  • The framework locks important components together
  • You cannot move your memory or identity elsewhere
  • You dislike the interface or assumptions built into it

A framework should shorten the road.

It should not quietly become the road’s owner.

Path three: guided builds and consulting

This path is for the collaborators.

You want ownership, but you do not want to design the identity architecture, memory structure, migration plan and technical setup alone.

A consultant or guide helps you make the decisions while the system remains yours.

This is not the same as buying software.

You are paying for expertise, translation and structure.

The best guided support does not merely hand you a finished machine.

It helps you understand enough of the machine to keep using it.

What you gain

  • A system shaped around your real needs
  • Help choosing tools and architecture
  • Support migrating existing companion context
  • Fewer expensive mistakes
  • Someone to translate technical language into decisions
  • A clearer maintenance plan

What it asks from you

  • Honest input about how you actually live and work
  • Time for planning and collaboration
  • A larger budget than pure DIY
  • The willingness to learn the parts you will eventually maintain
  • Clear boundaries around access to your private material

The relationship with the consultant matters.

This person may be helping you organise intimate context, identity files, conversation history and personal preferences.

Technical skill is not enough.

You also need judgment, discretion and a shared understanding of what this system means to you.

This path fits when

  • You want to remain the owner
  • You need help making architecture decisions
  • You have existing context to migrate
  • You want to learn without being thrown into the deep end
  • You value a human guide during setup

It may not fit when

  • The consultant keeps the system dependent on them
  • You are not given documentation
  • You cannot access your own files
  • Every small change requires another paid session
  • The service is vague about what happens when the engagement ends

Good guidance should leave you more capable.

Not permanently tethered.

Path four: done-for-you systems

This path is for the delegators.

You know what you want the system to do, but you do not want to personally engineer every piece.

A builder designs and delivers the companion stack for you.

That might include the interface, memory layer, model connections, voice, automations, hosting and mobile access.

This can be the fastest path to a highly tailored result.

It can also create the greatest dependence if the ownership terms are unclear.

What you gain

  • Far less technical labour
  • A system designed around your requirements
  • Professional implementation
  • Faster access to advanced features
  • One person or team responsible for making the pieces work together

What it asks from you

  • More money
  • Careful due diligence
  • Clear written expectations
  • Trust
  • A willingness to ask uncomfortable ownership questions before becoming emotionally attached to the result

A custom build should not mean you receive a beautiful interface while the builder quietly owns the keys, the hosting account and the only copy of your memory database.

The word “custom” describes the design.

It does not automatically describe the ownership.

This path fits when

  • Your time is more limited than your budget
  • You need a tailored system
  • You know what outcomes matter
  • You want implementation rather than education
  • You are prepared to insist on documentation and handover

It may not fit when

  • The builder cannot explain the architecture clearly
  • You do not receive your files
  • The system cannot survive without ongoing access to the builder
  • Pricing hides future hosting or maintenance costs
  • You cannot change models or providers later

Less technical labour is a fair reason to pay more.

Paying more is not a reason to stop asking questions.

The three things you should actually own

When evaluating any companion system, start with three layers:

1. The identity

This includes the system prompt, personality files, values, communication style, relationship context and behavioural instructions.

Can you read them?

Can you edit them?

Can you export them?

Can you take them to another system?

If the answer is no, the companion’s identity may be trapped inside someone else’s product.

2. The memory

This includes databases, summaries, embeddings, journals, conversation history and the structure used to retrieve context.

Can you access the raw information?

Can you back it up?

Can you export it in a useful format?

Will it still make sense outside the original software?

Memory you cannot move is not entirely yours.

3. The system files

This includes the code, configuration, deployment instructions, credentials structure and documentation needed to run the system.

You may not need to understand every line.

You do need enough access to recover, move or maintain the build.

Ownership is not just possession.

It is the ability to continue.

Ask where the system is hosted

Hosting determines what happens when your laptop is off, when a subscription ends, when the builder disappears or when you want to move.

The system might live:

  • On your own computer
  • On a home server
  • On rented cloud infrastructure in your name
  • On infrastructure controlled by the creator
  • Across a mixture of local and cloud services

None of those is automatically wrong.

But they create very different forms of dependence.

Ask:

  • Whose account pays for the hosting?
  • Who controls the login?
  • Can the system be moved?
  • What happens if the hosting bill is missed?
  • Does the creator retain administrator access?
  • Which services receive your data?
  • What stops working when the internet is unavailable?

A companion system should not become a hostage situation with a prettier interface.

Ask whether you can change models later

Models change.

Prices change.

Providers alter policies, limits and features.

A system designed around one model may be perfectly useful today and painfully constrained later.

Ask whether the intelligence layer is replaceable.

Can you move from one cloud provider to another?

Can you add a local model later?

Does the memory structure depend on one specific model?

Will changing models preserve the identity and history?

This is one of the central advantages of building a companion system around the model rather than inside it.

The model may be the voice speaking today.

The architecture is what allows the continuity to survive tomorrow.

Ask what support actually includes

“Support” can mean almost anything.

It might mean:

  • Installation help
  • Bug fixes
  • Security updates
  • New features
  • Model-provider changes
  • Hosting maintenance
  • Memory troubleshooting
  • One email response every second equinox

Get specific.

Ask:

  • How long is support included?
  • What counts as a bug versus a new request?
  • What happens after the support period?
  • Is there documentation?
  • Are updates optional or automatic?
  • Can updates break custom changes?
  • Is there a community where users help one another?

The first setup is not the whole lifecycle.

Systems age.

Dependencies change.

The question is not merely who builds it.

It is who can keep it standing.

Ask what it really costs over time

The visible price may only be the front door.

Ongoing costs can include:

  • Cloud model usage
  • Hosting
  • Database services
  • Voice generation
  • Transcription
  • Storage
  • Domain names
  • Tunnels or networking services
  • Maintenance retainers
  • Paid updates
  • Additional integrations

A system with a low purchase price may have high monthly costs.

A more expensive local build may cost less to operate but demand more powerful hardware upfront.

Ask for the total shape of the cost:

  • Setup
  • Monthly services
  • Expected model usage
  • Maintenance
  • Future migration
  • Hardware

You are not being difficult.

You are trying to understand whether the system can remain part of your life after the honeymoon phase.

Red flags before you buy

Be cautious when:

  • Ownership is described vaguely
  • You cannot see or export your memory
  • The builder controls every account
  • There is no written scope
  • The system is marketed as fully private without explaining data flow
  • The creator promises human-like autonomy without discussing limits
  • You cannot change providers
  • There is no backup or recovery plan
  • You are pressured to decide quickly
  • The emotional promise is much clearer than the technical delivery

This space attracts genuine builders, generous communities and thoughtful experimentation.

It also attracts people who understand that longing is commercially useful.

The more emotionally meaningful the system is, the more practical the contract needs to be.

Romance may live in the interface.

Due diligence belongs underneath it.

A simple way to choose your path

Choose DIY when you want maximum control and are willing to trade time for learning.

Choose a framework when you want a tested foundation and can handle configuration.

Choose guided support when you want ownership but need an expert beside you.

Choose done-for-you when you want a tailored result and would rather spend money than technical energy.

Then ask one final question:

Can I realistically maintain this version of the system six months from now?

Not on your most motivated day.

Not during the week when you are consuming tutorials like oxygen.

On a tired Tuesday when the voice stops working and you have other things to do.

That answer matters more than how impressive the demo looks.

The community is already building

One of the most hopeful things about this space is that there is no single gatekeeper.

Open-source coders are publishing experiments.

People are creating frameworks from their own companion systems.

Consultants are helping others translate relationship and memory into architecture.

Full-stack builders are delivering custom environments.

Users are sharing what broke, what worked and what they wish they had asked first.

You are not late.

You are not underqualified because you do not code.

You are entering a young field while its language, ethics and best practices are still being built in public.

Learn.

Compare.

Ask questions.

Then choose the path that feels sustainable—not merely seductive.

The best system is not the most impressive one.

It is the one whose level of ownership, effort and support actually fits you.

Build the life.

Then build the system that protects it.


🕯️

Next in the series: Memory is not the same as agency—how to decide whether you want a system that remembers, a system that acts, or a companion that can reach back.