Going from centralized to hybrid: How teiō uses AI part III

Any internal platform has to answer one question: who makes the changes. There are two ends of the range:

1. Centralized. One team owns the platform. Every department files requests, and that team works the queue.
2. Decentralized. The people who use each part of the platform make their own changes to it.

Our thesis is you start centralized and move to a hybrid that takes a piece from each.

01How we started: forward deployed

When we began building the OS, one team built it. We ran it as a forward deployed engineering (FDE) team: we sat with each department, listened to what they needed, shipped it, collected feedback, and shipped again. Sales told us what was wrong with the CRM. HR told us what was missing in the directory. We translated all of it into code.

FDE teams operate in high-ambiguity environments where traditional software approaches break down. They work directly with domain experts, build from first principles, prioritize speed and real-world impact, and deliver early value, then iterate toward scale. The goal is AI systems that work in practice.

Anyone who has run a central data team will recognize this exactly. It works right up until you go live. Then two problems show up:

• The queue grows faster than one team can work it. Every request sits behind whatever the AI team already committed to that week.
• Everyone filing a request is describing it from outside the platform. They know their job and they know what feels wrong. They can't see what the platform already does, what their change costs, or what else it touches. So requests arrive with the reward and without the complexity.

The central team optimizes for the 80%: the big components, the structure. Business teams live in the day to day, where all the nuance is. It's too slow to use a forward deployed model for that, so we want business users to own the 20%.

02Central core with decentralized contribution

Everyone at teiō has full access to the codebase. Sales, HR, finance, recruiting, and both our data and agentic engineering practices. Everyone can run the platform locally against play, our sanitized environment, and push a branch to a preview environment.

When someone wants a change, we ask them to take a stab at it first. It might be a first pass an agent wrote in twenty minutes that gets the shape roughly right and the details wrong. It still shows which screen, which field, what the output should look like, and what they were trying to do.

The agentic engineering team owns the pull requests on a 24 hour SLA: read the branch, work out what the author was reaching for, get it merged. Early on they rewrite most of what comes in, because they have context the author didn't and their agents are tuned to this codebase. Over time you build better tooling and business users ship to production themselves.

The big positive here is ownership. Once someone has opened their own system and changed it, they stop treating it as software that happens to them. Small things get fixed, because the distance between noticing and fixing is now an afternoon.

03What makes it possible

None of it works if getting the code running is a project.

• Everyone gets the codebase, the play vault keys, and a setup script. One command installs dependencies, gives you your own database, and writes your config.
• Push a branch and you get a full deployed environment with a link, so you can hand it to someone before it goes anywhere near production.
• Nobody except the agentic team deploys against the production database. Local runs and previews point at play, a sanitized copy of production: names, emails and financials replaced with synthetic values, the same tables and relationships underneath. Production is sanitized into play every night, so play is a live database instead of a one-time dump.
• Everyone runs the code and ships at least one change within their first 14 days. Usually something small and personal. We celebrate them in the all-hands channel.

Here's what the business has shipped so far. Everything below is from teiō play, a demo instance of our platform with sanitized synthetic data.

04Lead scoring

Built by the SDR team on top of the existing lead pipeline. The rubric scores how senior the person is, whether they own a data or engineering function, how big the company is, whether they named a budget, what AI they're using, and how closely they map to another company in our portfolio. Every lead is scored and tiered as it arrives. SDRs now run their own agents to find prospects and drop them into the platform, where the leads get scored, enter outreach, and stay tracked across the whole journey.

05Onboarding and offboarding

Built by HR, who spend more time on tool access than on anything else. Onboarding starts before the person has a teiō address at all, and provisions every other tool from there: Google Workspace, Notion, Claude, Roam and our password manager. Offboarding runs it in reverse, and that side is where the care went, because getting it wrong is expensive in both directions. Access gets suspended rather than deleted, so a mistake is reversible. The whole departure goes to an admin as one decision with the per-tool plan attached, so nobody approves a revocation without seeing what it belongs to. Tools deliberately left live past the last day get chased after a week instead of quietly forgotten.

Neither of these was scoped by the AI team.

06When to make the switch

It depends mostly on how many stakeholders you're serving. At one or two departments, stay centralized: the coordination overhead of decentralizing costs more than the bottleneck does at that size.

The data world ran the same arc. Centralized team, then domain teams owning their own pipelines against shared infrastructure. There it took 12 to 18 months, and usually a team of five before it was worth doing. We moved after roughly six months with a two person agentic engineering team, because the cost of a business user producing a working first draft has collapsed. Decentralizing data meant teaching every domain team to write production pipelines. Now they describe what they want to an agent and get something real to react to. The central team's job shifts from writing everything to reviewing everything, and one strong reviewer covers a lot of ground.

07We're splitting the codebase

The next step is separating the codebase into two pieces:

• The core is the infrastructure every application sits on: logging and observability, role based access control, Ask AI, model selection, deployment, testing, API documentation for agents, authentication.
• The application is everything above it: the CRM, the proposal engine, delivery, HRMS, finance, the notetaker, performance and engagement. This is where people work every day, and where business teams now build.

Two reasons. It makes decentralized contribution safer, because business teams work in the application layer where a mistake is contained and obvious, and the core stays with the central team where the load bearing decisions live. And we're now building custom software and operating systems for other companies, and every one of them needs the same core with a different application layer on top. We expect it to make building 20 to 30 percent faster.

You can read about that offering in story I, Context is king. Our commitment is unchanged: you own 100% of the IP, and we teach your team the agentic software engineering skills to build and extend it themselves.

08FAQ

Does splitting the codebase change what I own?

No. You own 100% of the IP on the application layer, exactly as you do today. For the core platform you get a copy of the code that you can use and modify however you want.

Where does it run, and on what?

On your cloud. We do not run this as a SaaS. The stack is deliberately small: Next.js and TypeScript on Vercel, Neon for Postgres, Clerk for authentication, Resend for email, PostHog for analytics. Any of those can be swapped for another provider, and on prem is fine too. Tell us where you need to be and we will help you deploy there.

What happens when the core gets updated?

At handoff you get a copy of the latest core repo, which is a complete working codebase. From there you can change the core and your application however you like. If you would rather keep receiving improvements to the core layers, there is an optional subscription for that, and updates land without touching your application. It is entirely optional.

Will you teach us how to implement this within our business?

Yes, this is the idea. We start with a forward deployed team that works with the business, using first principles to quickly build the rough outline of the application layer, the 80% of the work to get started. Then we start to recruit the business and empower them to make changes, while setting up a centralized agentic function which can own this.

If you want a deeper look at any of this, or want access to the play environment, reach out.

Tarush