Skip to content

Extending WilsonOS

WilsonOS is built for digital products and marketing first, and the architecture is broader than that. The tension is deliberate: a product that can be extended in any direction is a product with no definition. So the system draws a line between the layers that are meant to change per business and the contracts that are preserved underneath them.

Five layers carry business-specific knowledge. Four of them change routinely; the fifth is real integration work.

flowchart TB
  subgraph change["Changes per business"]
    S[Skills<br/>specialised judgement and method]
    F[Flows<br/>reusable orchestration of work]
    B[Brand context<br/>products, audience, voice, constraints]
    N[Connections<br/>systems to read from or act in]
  end
  subgraph sometimes["Sometimes — deliberate work"]
    M[Additional business records,<br/>access rules, and interfaces]
  end
  subgraph keep["Preserved"]
    L[The work loop · the foundations · the record vocabulary]
  end
  change --> L
  sometimes --> L

Skills — specialised judgement and method

Section titled “Skills — specialised judgement and method”

A skill is one atomic capability: write a Pinterest post, render a brand book, score a video title, outline a course. It is brand-agnostic — it loads the brand context at run time — and it declares up front exactly what context it needs, so nothing loads “just in case”. Skills are the unit of mastery. The catalogue holds a few hundred of them, indexed by category, job, and status, and an agent is expected to check the catalogue before improvising.

A flow is a multi-step orchestration that produces an outcome: take a brand from no Pinterest presence to posting weekly; produce an advertising campaign end to end; run a daily brief. Flows sequence skills, declare the context needed across the whole arc, name the points where a human decision is required, and gate anything that spends money behind explicit approval. Agents execute flows; flows call skills. Both are brand-agnostic.

Brand context — what makes the same flow produce different work

Section titled “Brand context — what makes the same flow produce different work”

Each brand carries its own stack: products, audience, voice, visual rules, customer language, positioning, lessons learned. A slim brand essence loads at session start; deeper documents load on need through links. Scout running the social-content flow for Code Pineapple and Prime running the same flow for RiseBlox produce different work because the brand stack, not the flow, carries the difference.

Connections — systems to read from or act in

Section titled “Connections — systems to read from or act in”

Publishing platforms, advertising accounts, media generators, document stores, analytics. Each is a named connection with an account scope, permissions, and a declared list of reads and actions. Adding one is configuration plus a catalogue entry; it does not change the loop.

Sometimes: additional records, access rules, and interfaces

Section titled “Sometimes: additional records, access rules, and interfaces”

A legal matter, an inventory item, or a patient record is not a product, offer, or campaign. Supporting an industry whose core records differ means adding business models, permissions, and user interface — and the docs say so plainly. Industry support is not guaranteed by adding a prompt.

Connectors bring data in; they do not automatically create production tables. A new source goes through four deliberate steps:

  1. Receive the source data with its provenance (where it came from, when, under what account) and an appropriate retention rule.
  2. Map familiar concepts onto the shared business records — this source’s “order” is our purchase event; its “audience” is our customer account.
  3. Preserve source-specific fields in structured extensions rather than discarding them or forcing them into the shared model.
  4. Add dedicated tables only when new relationships, permissions, reporting, or workflows justify them.

Metric definitions, identity matching across sources, and schema changes are integration work with an owner and a review — never a side effect of turning a connector on.

Extending never touches three things:

  • The work loop. A new industry does not get a ninth station.
  • The foundations. New data still has one canon and one writer; new users still get default-deny access; new connections still go through a named gateway.
  • The record vocabulary. A product is a product in every brand; extensions add fields, they do not redefine the noun.

live Skills, flows, brand stacks, and catalogued connections are the working extension mechanism today. direction The four-step intake for new data sources is the agreed rule; specific sources are at different stages of it.

Sources: input/WilsonOS_Overview.html §06, docs/architecture/skills-and-flows.md, docs/architecture/connections.md · Last verified 2026-09-15