What We Learned Running Our Own Agency on a Company OS

Skein runs its own agency on a Company OS: every report, plan and piece of content it delivers goes through the system it builds for clients. The biggest lessons were not about AI models. They were about written methods, where people must approve, treating access as separate from permission, and keeping knowledge out of any one person's tools.

Why run an agency on its own Company OS?

Because selling a system you do not use is hard to defend, and running it daily is the fastest way to find what breaks. Every deliverable Skein produces runs through the same company brain, written methods and agents it builds for clients. That includes audits, articles and weekly reports, and it keeps the method honest.

There is a practical reason too. An agency's work is a good test bed, spanning research, writing, analysis, reporting and client communication. Often that happens across several clients a day. If the system holds up there, it usually holds up inside a client's business.

It also keeps us close to the problem the system solves. According to Atlassian's 2026 Pulse survey, only 12% of workers say their AI understands their organisation like a tenured senior colleague. Building that understanding, one written file at a time, is the daily work.

What did we build first?

Written methods. Before any agent, each core job was written down as steps, checks and examples, in the words of whoever did it best. Then came the shared foundations those methods read: product facts with approved claims, the ideal customer, the voice. Agents came last, because an agent is only as good as what it reads.

The order matters more than any tool choice. An agent built before its method produces fast, generic work. Given a written method and approved facts, the same agent produces work that needs light review rather than a rewrite.

Next came a decision about where methods live: in shared files, not in anyone's personal setup. One rule followed directly. A standard that applies to every client goes in the shared wiki, never only in one person's AI memory. Memory on one laptop is something nobody else gets.

New client work got an order too. Foundations are drafted from public information first, then refined with the client's own material. Finally, they are confirmed in a discovery call. Nothing at draft maturity goes into live work.

Where do humans still decide?

Wherever work becomes hard to undo. AI drafts, researches, checks and prepares freely. A named person approves anything published under a client's name, sent to a real person, or that spends money. That line does not move, even when the work looks finished and even when someone says it looks good in conversation.

The gates differ by channel, but the shape is the same. For outbound, AI may load an approved campaign into the sending tool, paused, and a person launches it. A paused campaign built wrongly is visible and fixable in minutes; a launched one has already reached someone's inbox.

For advertising accounts, changes split three ways. Reversible hygiene needs an approver's sign-off. Budgets and targets belong to the client, and a person changes them on screen. Ad wording is approved by the client before a person turns it on.

The gates proved to speed things up rather than slow them. People trust and use output they know will be checked before it reaches a customer.

What broke, and what did we change?

Three things changed how the system works. A connection's access turned out to be wider than what it should do, so rules and locks now sit between the two. A guard once refused everything after a tool changed, which confirmed that guards should fail closed. And small habits, such as punctuation, proved to matter more than expected.

Access is not permission. Several business tools connect through keys that can do far more than the job needs, such as sending, publishing or deleting. Some offer no read-only option at all. So every connection now has a written rule saying what AI may do. The riskiest also have code that refuses anything outside an allow list. The evidence for caution is strong. According to IBM's 2025 Cost of a Data Breach report, 97% of organisations that reported breaches of AI models or applications lacked proper AI access controls.

Fail closed. One allow-list guard was written for an older version of a tool. When the tool changed its format, the guard refused every request, including harmless reads. That was the right failure: nothing happened that should not have. It was rewritten the same day, and version changes are now checked before they are adopted.

Small habits carry signals. The long dash became a banned mark in anything a client reads, because readers increasingly treat it as a sign of machine-written text, and it is rarely the mark a client's own writing uses.

What would we do differently?

Write the rules for each tool before connecting it, not after. Deciding up front what each connection may do, and refusing everything else by default, would have saved most of the tightening later. Approval points are similar: define them when a workflow is designed, not when its first output is ready.

Keep knowledge and method separate, too. How an audit is run belongs in the shared wiki. Facts about a particular client belong in that client's own workspace. Mixing the two makes both harder to maintain, and risks one client's details leaking into another's work.

What does this mean for a client?

It means the system a client gets has already been through daily use, with the approval points, access rules and guards that use exposed. A client's own Company OS is built the same way, in accounts the client owns, so it keeps working whether or not Skein stays involved.

The broader lesson applies to any business adopting AI. According to MIT NANDA's 2025 study, 95% of the organisations it studied saw no measurable return from generative AI, and the authors blamed systems that do not adapt to context or learn. Running a Company OS daily is mostly the unglamorous work of making the system learn: writing things down, keeping them current, and deciding who approves what.

The architecture is set out on the Company OS page.

The Company OS pillar explains each layer. Building one suits a growing B2B team that wants AI working from its own knowledge. A team of two or three may only need a tidy shared folder and a couple of written methods.

Frequently asked questions

Does Skein use its own Company OS?

Yes. Skein runs its own agency on a Company OS, and every report, plan and piece of content it delivers goes through it. The same company brain, written methods, agents and approval gates it builds for clients are used daily in its own work.

What should you build first in a Company OS?

Build the written methods first: how each core job is done, in the words of whoever does it best. Then build the shared facts those methods read, such as product facts, the ideal customer and the brand voice. Agents come last, because they depend on both.

Where should humans approve AI work?

Wherever work becomes hard to undo: anything published under the company's name, sent to a real person or that spends money. AI can draft, research, check and prepare freely. A named person approves before anything crosses that line, and the line should not move.

What does access is not permission mean?

It means a tool connection that technically can write, send or delete still needs a rule saying what AI may actually do with it. Many API keys allow far more than a job needs. Written rules, and code that refuses anything outside an allow list, close that gap.

What is the biggest lesson from running a business on AI?

Most of the work is not about AI models. It is writing methods down, keeping shared knowledge current, deciding who approves what, and limiting what each connection may do. Those habits decide whether AI produces trusted work or fast, generic output that needs rewriting.

Related reading