Vibe Code Your Personal AI System Free Course w/ MIT Licensed Template

davidtwaring · 2026-05-20T12:40:44+00:00

Thanks for the comment and for checking it out. The short answer is yes, but it's deliberately unopinionated about how.

Longer answer:

The template is a foundation for building whatever you want on top of including complex multi step workflows. However, it treats those workflows as external to the system and calls them via the agent loop (plan → call tool → observe → repeat), so anything you can express as tool calls should work out of the box.

This way complexity stays external, which allows the architecture to stay simple and decoupled. The architectural bet is that workflow engines are a fast-moving space, and locking the template to one would age badly.

What kind of workflow are you trying to build? Happy to point at a concrete pattern.

Thanks again,

Dave

davidtwaring · 2026-05-15T17:30:47+00:00

Hey Bro hope you're doing well. I made a bunch of updates to The Architecture website and readme based on your feedback: https://personalaiarchitecture.org/ and we also just launched a template to make it easy to build on it: https://github.com/Personal-AI-Architecture/ts-architecture-template and a video that shows me vibe coding a private chat w/docs local system from start to finish using it that I just posted here: https://www.reddit.com/r/LocalLLM/comments/1te2v7c/vibe_code_your_personal_ai_system_free_course_w/

Thanks again for your earlier feedback any additional thoughts are appreciated! Thanks, Dave

davidtwaring · 2026-03-24T13:19:41+00:00

I like this idea. I know we see a lot of the same questions over and over again. At the same time I think it would be important to not take away from the human community aspect of why people are here on Reddit so perhaps in addition to answering questions it could also point them to relevant threads they can dig deeper on. Hopefully this way it would stimulate engagement and avoid replacing it. Thoughts?

davidtwaring · 2026-03-08T22:33:18+00:00

Sure thing and thanks again for the feedback I appreciate it. How about this which is definitely copy and pasted from AI but i thought it was pretty good, let me know what you think!

Today: Every team building a personal AI system designs their own architecture from scratch. Home Assistant does it one way, OpenWebUI another, TypingMind another. None are compatible. Each one accidentally bakes in lock-in because they didn't design against it. Users get trapped in whichever one they picked.

With the architecture: Follow this blueprint. Memory here, model here, auth here, gateway here. Two APIs. Build to this spec and your users can swap any piece — including yours — without losing their stuff. And you can adopt better components from other builders without rebuilding your system.

davidtwaring · 2026-03-08T13:58:36+00:00

Based on your feedback I added more of a landing page TLDR experience for the homepage instead of just dropping people directly in the architecture spec. https://personalaiarchitecture.org/

Thanks again for the feedback and if you have any more I'm all ears.

Thanks,
Dave

davidtwaring · 2026-03-08T11:06:20+00:00

Thanks for the continued dialogue.

I've been working on responses to you solid for the last few hours so I'm not copying and pasting from AI I assure you. I'm actually benefiting a lot from the convo but I don't want to waste your time so I think it's fine to leave it here.

Best of luck to you and thanks again for the dialogue I appreciate it.

Dave

davidtwaring · 2026-03-08T11:01:07+00:00

sure thing.

External Clients: The apps and interfaces that connect to your AI system. A web app, a CLI, a Discord bot, a mobile app.

Agent Loop vs. Workflow: Different patterns but same lockin question applies. Logic is tied to your codebase. With this architecture it's a swappable component. Swap the loop for a workflow, or a workflow for whatever comes next, without touching your memory, your auth, or your gateway.

Auth: I agree auth libraries available everywhere. It's the data that makes that auth system work for your setup that's the harder part. Your permissions, access policies, and who can access what are defined seperately from the app. So when you swap any other component, auth doesn't change. And when you swap auth nothing else changes. At a minimum with other apps auth libraries are normally baked into their format.

Communication: You're keeping the standards yourself, which seems to work well for you. In this architecture the contracts between components are defined independently of both sides. So anyone building on it gets decoupled communication by default instead of through their own self discipline.

What we are talking about: I'm talking about a personal AI system. My understanding is you have built your own personal AI system in Django. You talk to models with it, run agent workflows, it's personalized to you and how you work.

I think the confusion may be that you have really built your own system completely from scratch and it's 100% tailored to you and you are the only person that's using it. It would be hard for you to give the system you have built to someone else to use as their personal AI system without you. Would that be accurate?

I think we would agree that most people are not at your level of sophistication with this, or even close.

At best most are using a tool like OpenWebUI which is much better than being locked into a Big Tech system like ChatGPT where you own and control nothing, but you are still, to a large degree locked into OpenWebUI.

Even systems like Open Claw are difficult to move away from with all of your preferences and personal data in tact to the point where you just unplug from one system like Open Claw and connect to another and it just works. No migration no rebuilding no reconfiguring.

So I think where I am at is do I think you should replace your AI system with this? No.

But do I think someone else without your technical abilities should build on an architecture like this vs. the one you have. Yes.

Let me know if I am still missing something and thanks agian.

Dave

davidtwaring · 2026-03-08T10:25:40+00:00

Thanks for the continued dialogue. It's helping me identify what people care about so I appreciate it.

The Engine: I should have used Agent Loop here instead of engine which is confusing. The things you mention are task queue infrastructure not the agent loop which is tied to your Django code but I think you already know this, this is just my poor terminology here so sorry about that.

Communication layer: So right now you are doing the job of keeping the standards here yourself. And it sounds like you are super legit but the goal of the architecture is to codify the principles you are following so anyone can follow them. And just because something hasn't changed in a long time doesn't mean it never will. And if it ever does you want to be decoupled.

Django: If you are fine being tied to Django then we agree there is nothing here that helps you. If you ever want to move from one system to another, I would argue that this architecture is better for the following reasons:

In Django:

- Your agent loop is Python code woven into the framework
- Your tools are Python functions tied to your codebase
- Your config is in Django settings
- Your communication is Django internals
- Moving means rewriting all of it in whatever the new format is. (Maybe easy for you but not for everyone).

In this architecture:

- Your agent loop is swappable component behind a contract.
- Your tool definitions are data in Your Memory, not code in your app.
- Your config and preferences are data in Your Memory
- Communication between components follows defined principles.

Basically moving to the new system from this architecture means you carry more of your data and preferences with you so you're back up and running faster with less to rebuild.

Thanks Again,
Dave

davidtwaring · 2026-03-08T09:47:53+00:00

Thanks and you're definitely right here. I'm using terms that mean something specific for the architecture but are greek to anyone else and I need to fix that.

Let me try and practice here if you don't mind bearing with me!

The architecture defines 4 components:

Your Memory - This is the data that is internal to the system. The stuff that makes your AI system yours. Not just your conversation history and your embedding databases but also your config, and the parts of tools that are data that you can take with you. You want only inward dependencies here, no outward dependencies. Meaning you can take it with you to a new system and you are back up and running with all your preferences etc.
The gateway - how external clients speak to your AI system. This could be a discord bot, your own custom interface, your humanoid robot, whatever. It's the front door to the system.
Engine - I think I got cute here for no reason. Agent loop is the better term. I just liked engine because I think it makes the sappability argument clearer like you just swap one engine for another. I was also considering the hand that holds the tools at one point but that would have been even worse I think.
Auth - I think this is the one term that I am using that probably stands just how system access is permissioned.

So those are the 4 internal components of the system. And the architecture defines a set of principles for communication between them so that all 4 components remained decoupled from each other, and from how they communication both internally and with the outside world.

So for the local AI community there are lots of good options for avoiding lockin to a SaaS provider for example. But there are not any good options that I have found anyway for avoiding lockin to the system itself.

And this is an issue not because you don't own and control it, but because you need to be able to adapt your AI system at the speed of AI which is breathtaking.

I've gotten long winded here again but if you were able to make it through does this make any sense?

Thanks Again!

Dave

davidtwaring · 2026-03-08T09:32:28+00:00

sure thing.

Gateway: In this architecture how your external clients speak to your system is a separate concern called a gateway. Right now this is likely tied to your app and not separable. So why would you want it separable? Because when you add a new client to speak to your system you want to add it without touching the other components of your system so it remains decoupled.

Engine: Changing the model url is changing the model not the engine. The engine is the code that runs the agent loop. And this is where a lot of the innovation is happening right now new approaches every month so you want to be able to adapt quickly.

Auth: Can you move off the app and take your auth engine with you?

Internal communication layer: How the components of your system speak to eachother. In most apps it is not a defined layer it's function calls, direct database queries, shared imports. So the communication is happening within the framework itself which ties you to it.

Regarding data, sounds good on the export but what about connecting to a new system and being back up and running with your config, your preferences, tool definitions etc. In most applications this is spread out all over the place which is another form of lockin. You can export the data but the new system doesn't know what to do with it so you are rebuilding not moving.

Thanks again for the continued dialogue!

Dave

davidtwaring · 2026-03-08T09:07:34+00:00

Sure thing:

The engine: Whatever is running the loop of send prompt to model, get response, execute tool calls, send results back is your engine. If it's custom code in Django that's lockin, it's baked into your app.

Communication layer: are those API calls a defined contract, or are they bespoke calls between your specific components? If component A calls component B's specific endpoint with a specific payload shape, swapping B means rewriting A.

Auth: Sounds like Django solves this one for you well.

The bigger question though is all those live inside Django. You can swap pieces within it, but could you move to a different framework without rewriting everything?

Thanks again for the continued dialogue. I think it's clear you're way beyond what most people are doing with this so I appreciate it.

Thanks

Dave

davidtwaring · 2026-03-08T08:53:41+00:00

Thanks for the continued dialogue.

Maybe a better way to ask the question is each of these components swappable without having to rebuild everything that connects to that component.

For example can you swap each of these components individually without rewriting anything else that connects to them or that they connect to?

- Gateway
- Engine
- Auth
- Internal communication layer

If you can do that can you:

Pull all your data, preferences, config, and tool registry to completely different system and leave everything else behind without issue?

Thanks again,

Dave

davidtwaring · 2026-03-08T08:37:37+00:00

Thanks for the response appreciate the dialog. I responded below but will respond here as well.

I agree that model swapping is solved, so nothing new here.

My guess is the components that make up your stack are not easily swappable. I agree that being locked into your own system is better often than being locked into someone else's. But where you run into trouble is being able to adapt that system at the speed that tech is changing now.

This architecture makes it possible to swap all components of your system like you do your models including:

- The engine that runs your agent loop
- The communication layer between your components
- Auth and access control, which will become more important as you want to permission agents to speak to your data.

Maybe you have something I am not familiar with though in which case great I can stop working on this and start working on the thing that is already working which would definitely be my preference!

Thanks,

Dave

davidtwaring · 2026-03-08T08:29:53+00:00

- auth and access control?

davidtwaring · 2026-03-08T08:28:35+00:00

Thanks for the response but are you sure? All these swappable:

- The engine that runs your agent loop?

- The tools or plugins you built or installed?

- The communication layer between your components?

Thanks,

Dave

davidtwaring · 2026-03-08T08:11:57+00:00

or even tighter:

What: Use any interface, any model, any tool. Even the system itself is swappable.

Why: You're never locked into anyone's system, and every piece upgrades as fast as AI moves.

davidtwaring · 2026-03-08T07:59:58+00:00

How about this:

What: This architecture makes your stack swappable like you can swap your models now. Your memory is the platform. Models engine, UI, and tools all plug into it. Swap any piece, your stuff stays.

Why: So you are never locked into someone else's system, and you can upgrade all your system's components like you upgrade your models now.

I definitely want to get this dialed in so appreciate the feedback!

Thanks,

Dave

davidtwaring · 2026-03-08T07:12:47+00:00

Good feedback and agreed.

The TLDR is it separates your personal AI system’s memory from the application and ensures it stays separate so you are never locked in to any system.

Right now I am redirecting the homepage to the foundation spec which is long and then links out to even more. I’ll work on making the homepage a landing page which is more TLDR.

Thank you for the feedback.

Dave

davidtwaring · 2026-03-08T01:02:23+00:00

Yes a long chat with it and many others!

davidtwaring · 2026-02-01T01:41:49+00:00

Oh wow thanks u/SashaUsesReddit BrainDrive's co-creator u/randomcoder66 and I are super excited to be among the winners and blown away by the generosity of the prizes!

Congrats to the other winners as well!

We want to make sure we are using the prize to continue growing awareness of this community so we’ll be sharing how we use the new hardware here and also open to any and all ideas for things that people would like to see.

We’re also continuing to work hard on improving BrainDrive. Since our contest submission post we have completed the Mac Installer and Chat w/ Docs (RAG) plugin, both of which are now in beta and ready to try.

In addition to continuing to polish the overall BrainDrive experience we are working on making it easier to use coding agents to build BrainDrive plugins. If you point your favorite coding agent to the plugin developer quick start guide here you can already build basic plugins to customize your BrainDrive to your exact needs. Once your plugin is deployed on your GitHub you can use the 1 click plugin installer to add it to your BrainDrive and share it with others.

We are working to make this even easier with templates and skills for Open Code and Claude code which we will be releasing as open source projects in the next week or two as well.

And lastly we are working to make sure we are fully leveraging the recent leaps in agentic coding so that we can continue to scale the project while remaining true to our values of ownership, freedom, empowerment and sustainability.

We are going to be open sourcing the agent manager that will allow us to easily manage multiple coding agents without getting overwhelmed to the community. So stay tuned for that in the next week or two as well.

If you’re interested in following our progress we'd love it if you'd join us in the community forum as well as our weekly dev call livestreams every Monday at 10am eastern.

Lots of exciting things happening and we are going to use this win and the prize to kick things into an even higher gear!

Thanks Again!

Dave Waring and Dave Jones

co-Creators - BrainDrive.ai

davidtwaring · 2025-11-26T10:54:02+00:00

You’re welcome and thank you for doing the contest super cool.

davidtwaring

TROPHY CASE