Six weeks to an AI-native organization

A mid-sized tech company on an epic mission

When I started working as an AI consultant, transforming an entire organization felt like a distant dream. Then I published a post about building two products in two weeks for a client, and a few weeks later the CEO of a mid-market tech company operating across two continents reached out. He agreed this was where the market was headed, and he wanted to talk.

What struck me in those early conversations was his clarity. He understood not just what it's like to build with AI, but what it takes to move a whole organization. Within a couple of calls, the conversation had shifted from building products to something much more ambitious: he wanted to give his people a dedicated season to stop, learn, and rebuild how they work, one department, one team, one individual at a time.

Our engagement inside that season was six weeks. This is an honest, anonymized account of what we did with them: what worked, what didn't, and what I'd do differently next time.

One company moving at two speeds

From a distance, it seemed as though half of the company had gone deep on AI and the other half hadn't really started. Up close it was more layered than that, and the layers explain why this transformation happened at all.

At the top sat several members of the leadership team who were building with AI non-stop, on the same addictive loop my own team and I had been in since Sonnet 4.5 was released. Building that much does something to you: it develops taste. They knew what a well-briefed agent feels like, what quality at speed looks like, what becomes possible when context is engineered rather than pasted. Taste is uncomfortable. Once you have it, you can see exactly what your organization is missing.

What they saw in their engineering organization was speed without depth. Roughly fifty developers were writing much of their new code with AI and shipping faster every week for it. But measured against what those leaders had experienced hands-on, the engineering org was still early on the agentic maturity curve: the engineers were prompting hard, but the legacy codebases weren't meeting them halfway. Test coverage was low and the risk of deploying bugs into production was increasing along with the rate of AI-generated code.

Across the rest of the company, product, operations, legal, finance, HR, most people were using AI the way consumers do. Copy, paste, session by session. Minimal tooling, little to no orchestration, no deterministic evaluation. Skeptical about what AI could actually do, they had put the power of agents into a tidy box of limited possibility.

This is the spot a lot of companies find themselves in, and it is more dangerous than it looks. The fastest layer keeps getting faster. Everyone else stays put. The distance grows on its own, week after week, until one part of the building is effectively operating in a different decade from the rest. Meanwhile, the risks posed by lack of governance and compliance oversight continued to grow.

Leadership had seen the next wave of AI coming and knew that to become a truly AI-native organization they had to push the envelope across all parts of the organization. This wasn't about having breakthrough productivity in one domain, it was about redesigning everything for the agentic era. They wanted every function working with AI, and they made learning non-negotiable for the season: it was expected to consume half of people's time, with revenue goals explicitly secondary while the organization transformed. And they were firm about one condition: when we left, their own people had to be running all of it. Not us.

They gave us six weeks.

Before we proposed anything, we spent time building our own understanding of the company: where the capability actually sat, where the friction was, what each business line needed. When I walked one of their business leads through that diagnosis during a stakeholder interview, his reaction told me we had it right:

"Impressed and at the same time scared that you have a very similar understanding of what my perception is."

— Leader of a business unit

Four consultants on four fronts

Most AI transformations fail the same way: a pilot gets built, it never reaches production, and nothing actually changes. We designed the team specifically against that failure mode.

I didn't do this alone. My partner in building Vibrana, Fatma Ghedira, is an organizational psychologist with a master's from Columbia University who spent seven years in leadership development at ThinkHuman, working with companies from Snapchat to Google to the World Economic Forum. She owned the human side of this transformation: workforce impact, role evolution, and the listening circles that told us how people were actually doing beneath the adoption numbers. Alongside her I brought in Stephan Ledain of AdaptAI, a consultancy focused on the governance and compliance side of AI transformation. Stephan had spent three years in this field and had never seen a leadership team willing to transform everything in a single quarter. We brought in an agentic engineer with a renewable systems background who spent thousands of hours building with AI from the GPT-4 days and knew context engineering inside out.

Our shared hypothesis: four consultants, each owning a distinct domain (strategy and product, engineering, governance and compliance, people and culture), could support the organization from four sides at once, so no function got left behind while another sprinted ahead.

The engineering front carried a challenge that isn't taught anywhere online yet: large-scale legacy codebase management with agents. Building a product from scratch with AI is one discipline. Extending production codebases with hundreds of thousands of lines, millions of users, and years of technical debt is a fundamentally different one. And leadership's ambition here was pointed. They didn't want marginally faster developers. They wanted their legacy systems to become agentically navigable, the kind of codebase where AI can eventually write all of the code, safely, with guardrails that never put the production environment at risk.

Their engineers were already using frontier models with million-token context windows. What was missing was the layer underneath. The repositories carried no agent-readable context files, the now-standard AGENTS.md pattern that hands an agent the map instead of letting it burn its context window rediscovering the basics. There was no internal map of each codebase living in the code itself, no skills or tooling that reflected the actual architecture rather than a generic setup, and no evaluation scripts making quality checks deterministic instead of a matter of opinion. The test suite didn't yet protect existing functionality well enough to let agents work with confidence, and the CI/CD pipeline had never been designed for AI-generated code arriving at volume, let alone for integrating governance, compliance, safety, security, and code quality into one system.

The demand was already there before we built anything. Within the first week, a developer asked in the engineering channel whether there were plans for shared AI rules and config files at the repository level that teams could use as a baseline, even right now. Their engineering lead's response: that's why it was the top priority for developers. When we walked him through the context-engineering approach, he didn't need convincing:

"I am fully open… if we have a central repo, and then you put some initial structure, and then provide feedback and start working on that, I think it makes total sense."

Head of engineering

What ensued was a slowly evolving set of context engineering patterns, skills, hooks and scripts that let every engineer contribute to the transformation of their legacy codebases, making the code more agentically navigable one test, doc and push at a time. It was the emergence of an organization-wide engineering harness, something that can only emerge from within and not be delivered by someone outside the organization.

What we built

Four things, at the same time, in parallel.

One map of the whole company. Most of what this company knew about itself lived in people's heads, old wiki pages, and meeting recordings nobody had time to watch. We pulled it into a single structured map that mirrors the organization exactly: every team, function, and role has its place, with its goals, decisions, and key documents beside it, written so an AI assistant can read it instantly. The payoff was immediate. Someone could ask what any team was working on that week and get an accurate answer in seconds, no meeting required. A new hire could be pointed at their team's space and start being useful the same day instead of after a week of meetings. It also raised the hardest question of the engagement, and in the end the client chose not to deploy it. More on that below.

Personalized AI training for every kind of role. A hundred people do not do one job. This company had more than twenty distinct job functions, from backend developers to legal counsel to recruitment, and one generic "how to write a prompt" session would have changed none of them. So we started by meeting people where they actually were: an AI readiness assessment per department, with roughly 80% of the organization completing it in the first week. From there, an algorithm sorted people into cohorts, each with a leader and a deliberate mix of skill levels so peers could pull each other along. Then we personalized further: a workflow that took each person's interview transcripts, objectives, tooling, and assessment results, and generated a two-week daily learning plan aligned with the actual work on their desk. Over the engagement, the organization completed more than 3,200 of these daily lessons. The role-based AI curriculum mapped that learning to each department's workflows and decisions.

Some learners outran the curriculum. A pair of client engineers moved so fast that one of them independently built an approach more advanced than the one their learning journey prescribed, and they began running sessions for their peers. That's exactly the shape you want a transformation to take: the moment the client's own people become the teachers, the consultants become optional.

There was also a new role. We called it the product builder: customer service representatives, designers, and product owners shipping full products end-to-end. Nobody had that job title at the start. By the end, it existed. The pattern repeated across the cohorts: people who found the terminal intimidating on day one were shipping working products within four weeks, once they realized they could simply talk to the agent in plain language about the work in front of them.

One of the product builders described their breakthrough as:

"I realized I could just talk to this thing like a caveman and it would build it for me. I didn't need to know how it all worked."

An agentic maturity model and a CI/CD pipeline to enforce it. The engineering side ran on codebases built up over years, well over a million lines between them. AI can write code against something that size fast, but left to itself it also quietly piles up problems. Working with their engineering lead, we built an automated maturity model that analyzed their codebases in real time and moved them up a level each: from level 2 to 3, and from 3 to 4, the point where teams can genuinely work agentically on large production systems. We then redesigned their CI/CD from scratch, wiring SonarQube, CodeRabbit, and Sentry into tiered gates with architectural invariants.

One decision mattered most: the rules stopped new problems without punishing the team for years of old ones. You set a line and improve from there, instead of trying to fix everything at once and shipping nothing. Each major part of the system also got a short, honest briefing the AI reads on its own, including the bits that look wrong but are deliberate.

What this unlocks is not the AI replacing the engineer. It's the opposite. One of their engineers hit an agent stuck in an infinite loop, applied his own domain knowledge to redirect it, and solved in ten minutes a problem that would have taken two days. Asked what made it work, his answer became my favorite line of the whole engagement:

"It's all about coworking."

An engineer

What's emerging is a paradigm of work where it's no longer about measuring humans in the chair but about enabling people to become better orchestrators and coworkers with agents. It's about understanding how agents work, what agents need and all the while staying connected to yourself and your needs as a human.

In the same way you wouldn't expect a brand new coworker to understand everything about your job or the codebase you are working on, you can't expect an agent to do the same. It takes time to prepare the context, to design the skills and create the harness to allow them to flourish in their job. Once engineers fully understood this, the breakthrough was near.

An agentic operating system. A team spread across offices and time zones loses real hours to coordination: logging time, running sprint boards, writing up meetings, keeping everyone in the loop. We moved that work onto an agentic operating system plugged into the tools they already used, nothing ripped out and replaced. Their ops team went from clicking across a dozen windows to working in a single terminal with their email, calendar, team messaging, and documentation in one place. Meetings turned into decisions and action items on their own. We also wrote a machine-readable specification for how sprints run in Jira, so every ticket and epic is checked against the agreed criteria deterministically instead of by nagging. And we kept time tracking visible to the whole team on purpose, as a trust signal rather than a monitoring tool.

The same pattern ran through the business functions, where the first automations were chosen for boring, measurable pain: a payout process worth roughly 720 hours a year once automated, a monthly people-team newsletter cut from about ten hours of work to one, and a legal workflow that removed around 80% of the copy-paste involved in checking data across their product lines.

Underneath all four workstreams sat the governance layer, built into how the company ships rather than bolted on. A shadow AI audit came first, and it surfaced unapproved tools in active use and data flowing through AI systems with no policy behind it. That's what most mid-market companies find when they look carefully. We then worked with the company's legal and data governance lead, who understood both the regulatory detail across multiple jurisdictions and how people actually worked, to design controls that fit their workflows rather than cut across them.

The result was a three-tier risk taxonomy that classified every AI system by the data it touched and the oversight it needed, plus six gates in the CI/CD pipeline, from credential checks at commit to human sign-off before any production push. The Data Processing Agreement became a living control document: new systems get classified, their obligations documented, and run through the gates. Controls stay invisible when everything is in order and escalate clearly when the stakes are real, so friction matches risk.

How we worked

The whole engagement ran on a two-team operating model. Their team represented the core departments, carried the organizational knowledge and context, made the key decisions, and interfaced with leadership. Our team was the delivery unit that took agreed objectives and implemented them agentically. They led the company: which teams went first, how it was communicated, what got decided. We led the AI: the architecture, the tools, the method.

Midway through, the CEO watched a recording of the company's global alignment call, and afterwards described his relief that "the transformation now rests on more shoulders" than his own. His personal learning phase was done; the organization was learning collectively. That, more than any deliverable, was the point.

The COO put it plainly in a one-to-one after the second sprint. He was candid that the start had been "a bit chaotic" and "very rushed," and then gave his verdict: we had come on board "on the fly," into "such a scope," and, in his words, done an "amazing job." Where things were heading, he was "quite satisfied."

The only real test of success was whether they could run it all once we were gone. They could, and the systems are theirs. There is no license to renew and no one to keep paying to keep the lights on.

What we'll claim, and what we won't

Six weeks is not long enough to run a formal ROI study, so I'm not going to quote a clean number I can't stand behind. What I can give you is real and specific:

• Roughly 80% of the organization completed an AI readiness assessment in the first week, across more than twenty job functions.
• The training system delivered 3,200+ personalized daily lessons.
• An automated payout process projected to save around 720 hours a year.
• A monthly newsletter process cut from about ten hours of team time to one.
• A legal data-checking workflow with roughly 80% of its copy-paste work removed.
• A customer support representative built a solution to a real customer pain point on her own, without engineering support.
• Asked in a live pulse survey whether they understood how the AI-native transformation connected to their actual day-to-day work, people averaged 4.4 out of 5, with almost two thirds answering a full 5.

The evidence I would actually stake the work on is simpler than any metric: real systems, in real production use, run by their own people after we left.

What was hard

An honest case study should cost something to write. Here is what did not go smoothly.

Everything, everywhere, all at once. Transforming every department simultaneously was the point, and it was also the hardest thing about the engagement. Half the organization had to keep the lights on and hit their existing targets while learning a new way of working. The strain concentrated in exactly the functions with the least slack: IT, HR, finance, legal, and customer support. One support lead named the tension directly: her team could not do hours of learning a day and handle the ticket volume. She was right, and pretending otherwise would have burned the goodwill the program depended on. Pacing the learning around real workloads, rather than through them, is the single biggest thing I now design for up front.

Agile is built for a scarcity that no longer exists. Before AI, developer hours were the scarcest resource, and agile ceremonies existed to protect them. When you can build at ten times the throughput, those same ceremonies start costing more than they save. You can spend three meetings aligning stakeholders on requirements, or you can build the prototype in an afternoon and send it around for review. That asymmetry broke rooms more than once, and it deserved its own write-up: I published the argument separately as "Beyond the Sprint."

Specifications are cheap; adoption is expensive. With an overloaded legal team, a stretched IT department, and a busy engineering org, it was easy to produce governance frameworks, CI/CD guidelines, and rollout plans, and much harder to get them implemented into live systems without side-by-side, hands-on time. Remote delivery amplified this. If I ran this engagement again, I would trade some breadth of documentation for more in-person implementation days with the teams who had the least capacity to absorb change on their own.

One map, one door. The company graph was the part of the engagement people responded to fastest, and it raised the hardest question. As a set of static text files, it gave anyone who could open it the same view of everything: every team's goals and decisions, every role, every workflow. That is not how a company actually works. Finance does not see what HR sees, and a team lead does not see what leadership sees. The client was not comfortable with every department, and every person, having the same level of information. Partitioning and permissions were not a feature to add on top of the graph. They were the whole question, and a folder of files cannot enforce them.

The second concern was less obvious, and the client was right to raise it. A graph like this holds a company's secret sauce: its workflows, its team, its process, everything that makes it what it is. An independent third party that has built and holds the entire graph is a concentrated vulnerability inside the organization, however good its intentions. The lesson I took away is that trust is not a control. If a company's knowledge layer can only be made safe by trusting the people who built it, it is not safe. In the end, the client decided not to deploy the company graph at all. The operating-system tooling we built for their ops team stayed exactly that: tooling, with no brain behind it.

What it led to

Those two concerns are why we built AIOS. It is open source and self-hosted, so a company's knowledge lives on infrastructure it controls and no outside party, including us, has to hold it. Partitioning and permissioning sit at the base layer, so what each department and each person can see is enforced by the system rather than by convention.

It is reachable over MCP, so people can use whichever AI client they prefer, and it comes with a CLI for developer tooling and workflow automation. It is available for anyone to build on at aiosbrain.dev.

Where this leaves you

The pattern this company caught early is coming for most mid-market organizations: one function racing ahead with AI while the rest of the building falls a decade behind, one week at a time. The fix isn't a pilot, and it isn't a tool. It's every function moving at once, with an operating system your own people run after the consultants leave.

If half your company is already faster than the other half, the gap is compounding while you decide. That's the conversation worth having now.

We now run AI-Transformation pods where a forward-deployed engineer pairs with a lead in a specific department (recruiting, finance, customer service, etc.) and develops workflow automations, tooling and solutions alongside the team, allowing for both delivery and enablement in a symbiotic way. We've found this method to be much more effective than company-wide engagements as it allows for AI transformation to emerge organically across the company through proven value exchange rather than top-down enforcement.

If you've reached the conviction that AI-native is the only way your company will survive, we'd love to come alongside you and support that journey to guide the people, technology, governance and product through to the next stage of evolution.

Who delivered it

• John Ellison, strategy and product
• Fatma Ghedira, people and culture
• Stephan Ledain (AdaptAI), governance and compliance
• An agentic engineer, engineering