Here is how I actually think about it. Most people hear "local AI" and picture a model running on a laptop or a device with no internet. That is not what we do here. What we care about is this: who controls the stack? At the AI Startup Foundry we run a hybrid model. That means: - An agent running locally on a local machine with M5 Silicon chip, using a local LLM as its brain. - The same agent architecture running remotely on a private server, using an LLM hosted on that same server or using a subscription with Open Weights. - Both talking to each other. Both under our control. No OpenAI. No Anthropic. No vendor deciding your pricing, your rate limits, or your deprecation schedule. The model can live on your machine, on your server, or on both. What matters is that you own the runtime and you decide where each task goes. And more importantly, you own and keep access to outputs at all times. Local for speed and privacy. Remote self-hosted for heavier workloads. Hybrid when you need both. That is the stack we build here. That is what the 30-day sprints are built around. If you are already running something, or about to ship something, on infrastructure you control, this is your room.

I focus on AI infrastructure as, in my view, getting it right early on saves a lot of hassle later. I do understand that most devs won't worry much until it's too late. I'm currently working on a couple of projects which need the right infra but there comes a time when infra should be sufficient to justify moving to the next step. One question for you:

Gave my first task to Hermes Agent with MiniMax M3 and it's seriously good. With a Token Plus plan it's such good value for the quality returned. Combine this with solid meta prompting and you are smiling as you see the tasks being developed and outputs being delivered. Give it a try and tell me what you think.

Wow, sometimes monitoring and handling AI Agents can feel like babysitting, or should I call it AgentSitting. You give a /goal prompt to your agent, it starts well, you are getting good results, and yet it leads to some basic issues which need attending to. You then realise it is time for a model update, then a server update, then a Agent update, which turns into a failing error for which Doctor --fix is not enough and you end up prompting until it survives the update and restart. It is a process, and you learn along the way until you trust it (and yourself) enough to update cautiously but confidently as you do have backups and a good memory system in place. How do you deal with updates and improvements?

Here's what I see every cohort: founders who nail launch day and then go dark for 6 weeks "iterating." Meanwhile, the scrappiest builders in the Foundry are shipping every 2 weeks and outlearning them. Iteration isn't polish time. It's your between-launch improvement engine. It's where you find out what you actually built vs what you thought you built. The loop is simple: 1. Ship something real 2. Get it in front of users fast 3. Watch what they actually do (not what they say) 4. Fix the 1 thing blocking them 5. Repeat Heap, Posthog, amplitude. Pick one. Look at the one event that's dropping off. That's your iteration target. VC-backed startups iterate slowly because they need board sign-off to change direction. You don't. That's your edge. The founders who win are the ones who shipped ugly, learned fast, and iterated faster. Not the ones who "waited until it was ready." So here's the question: what's the one thing users are doing that you didn't expect? And are you fixing it this week, or waiting for the next launch? If you want a group of founders who actually do this every 2 weeks instead of talking about it, you know where to find us.