endoskeletal kernel 1 · lib 2026.09

SaaS organizations

Organization shapes

Software companies come in a handful of recognizable shapes. Each is a different arrangement of the same ten primitives: which scopes exist, which seats they contain, who holds which powers, and where agents sit. Here are four common ones, drawn as trees and written as code.

Seed stage: two founders and a team of agents

Seed-stage SaaS: two founders and a team of agentsNorthwindCEOfounderCTOfounderDeployerships low-riskprogramOpsscales in envelopeagentSupporttriage + draftsLLMArchitectsandbox onlyagentEngineengine
Seed-stage SaaS: two founders and a team of agents.
Text description of this diagram
  • Northwind
    • CEO — founder
    • CTO — founder
    • Deployer — program, ships low-risk
    • Ops — agent, scales in envelope
    • Support — LLM, triage + drafts
    • Architect — agent, sandbox only
    • Engine — engine

Two people, and everything else is a program or an agent with a narrow, compiled envelope. The founders are the constitution: every amendment needs both. Agents can do a lot, but only inside envelopes, and anything expensive or irreversible routes to a founder with a deadline.

northwind.eskesk
scope Northwind : org.Organization {
  persona NorthwindCo

  use gov.Constitution(
    founders = { CEO, CTO },
    amendBy  = CEO,
    board    = CTO,
    quorum   = 1,
    delay    = 2 d
  ) as Const

  position CEO : org.Owner {
    cardinality 1
    eligible when self is pp.Person
  }

  position CTO : org.Officer {
    cardinality 1
    eligible when self is pp.Person
  }

  position Deployer : org.Member {
    cardinality 1
    eligible when self is ag.Program
  }

  position Ops : org.Member {
    cardinality 1
    eligible when self is ag.Autonomous
  }

  position Support : org.Member {
    cardinality 1
    eligible when self is ag.ModelBased
  }

  position Architect : org.Member {
    cardinality 1
    eligible when self is ag.Autonomous
    incompatible with Ops
  }

  use rz.RealizationEnvelope(
    holder      = Ops,
    requirement = Api,
    operation   = ops.Scale,
    admissible  = a.n <= 12
                  and holds ops.price(bound(Api)) * a.n <= 4_000 USD per month
  ) as OpsEnvelope

  use org.Approval(
    approver   = CTO,
    subject    = ops.ScaleRequest,
    threshold  = true,
    deadline   = 1 business-days,
    escalateTo = CEO
  ) as ScaleApproval

  use rz.ExperimentPower(
    holder   = Architect,
    pattern  = Experiment,
    budget   = 200 USD,
    duration = 1 d
  ) as Research

  use fin.Budget(
    scope    = Northwind,
    resource = econ.Money,
    limit    = 18_000 USD per month,
    reserve  = 2_000 USD,
    window   = month,
    orElse   = gov.Freeze(except = { Const.Materialize })
  ) as Runway
}
  • Constitution of two. Both founders are founders; either can propose, and the CTO's vote is the quorum on constitutional change.
  • Agents with envelopes. Ops scales up to 12 units under a cost cap; the Architect researches in 200-dollar sandboxes; Support's outputs are claims at N until the founders' trust policy says otherwise.
  • Runway as a rule. A monthly budget with a freeze keeps the company inside its burn, and the reserve keeps the compiler able to apply an approved raise.

Product-led growth: squads, a platform, a guild

Product-led growth SaaS organized in squadsBrightlineExecCEO · VP Eng · VP ProductProductPlatformGTMWeb guildmember when …GrowthPM · EM · 4 engActivationPM · EM · 3 engBillingPM · EM · 3 engSREon-call 2..DeployerprogramSelf-serveLLMSales assist
Product-led growth SaaS organized in squads.
Text description of this diagram
  • Brightline
    • Exec — CEO · VP Eng · VP Product
    • Product
      • Growth — PM · EM · 4 eng
      • Activation — PM · EM · 3 eng
      • Billing — PM · EM · 3 eng
    • Platform
      • SRE — on-call 2..
      • Deployer — program
    • GTM
      • Self-serve — LLM
      • Sales assist
    • Web guild — member when …

Autonomous squads each own a slice of the funnel. A platform team keeps production running. A guild cuts across squads without owning anything. The interesting parts are what squads may do alone and what they may not.

brightline.eskesk
pattern Squad(focus : Text) {
  scope S : org.Team in Product {
    persona SquadP

    position PM : org.Officer {
      cardinality 1
    }

    position EM : org.Officer {
      cardinality 1
      incompatible with PM
    }

    position Engineer : org.Member {
      cardinality 2..6
    }

    norm Experiments {
      power of PM to decide launch | stop about growth.Experiment
      when e.traffic <= 20 % and e.squad = here
    }

    norm ShipsOwnCode {
      power of EM to authorize execute about eng.Deploy
      when c.owner = here and c.risk = "low"
    }
  }
}

use Squad(focus = "acquisition") as Growth
use Squad(focus = "onboarding")  as Activation
use Squad(focus = "revenue")     as Billing

-- Pricing changes cross squad boundaries: Billing proposes, the VP Product decides after Finance reviews.
use gov.ReviewedProposal(
  kind       = growth.PriceChange,
  approver   = VPProduct,
  reviewer   = Finance.Lead,
  deadline   = 5 business-days,
  escalateTo = CEO
) as PricingRoute

scope WebGuild : org.Team in Brightline {
  member when self member of Product and holds eng.frontend(self)

  norm Standards {
    power of persona to enact _ at level operational about eng.FrontendStandard
  }
}
  • One pattern, many squads. A squad is a pattern instantiated three times; changing the pattern changes every squad, with provenance.
  • Local autonomy, bounded. A PM can launch experiments up to 20 % of traffic; an EM can ship the squad's own low-risk code. Anything beyond is a proposal.
  • Guilds as scopes with computed membership. Members are whoever works in Product and holds the frontend claim; the guild can enact operational standards and nothing else.

Platform and stream-aligned teams

Platform and stream-aligned teamsCorvidStream-alignedPlatformEnablingSubsystemCheckoutSearchMobileoffers CIoffers Deployoffers ObserveSecuritytime-boxedBilling enginespecialists
Platform and stream-aligned teams.
Text description of this diagram
  • Corvid
    • Stream-aligned
      • Checkout
      • Search
      • Mobile
    • Platform
      • offers CI
      • offers Deploy
      • offers Observe
    • Enabling
      • Security — time-boxed
    • Subsystem
      • Billing engine — specialists

In the Team Topologies shape, stream-aligned teams consume what the platform team offers. In Endoskeletal that is literal: the platform team offers capabilities with contracts, and stream teams require them. The contract is the API between teams.

corvid.eskesk
scope Platform : org.Team in Corvid {
  persona PlatformP

  offers capability Deploy {
    operation deploy(c : Entity) -> outcome : Claim
    guarantee eventually holds eng.deployed(c) or holds eng.rolled-back(c)
    property  lead-time    <= 15 min
    property  availability >= 99.9 % per month
  }

  offers capability Observe {
    operation probe(r : Capability) -> observations : Claim
    property  freshness <= 1 min
  }
}

scope Checkout : org.Team in StreamAligned {
  requires capability ShipCheckout {
    operation deploy(c : Entity) -> outcome : Claim
    property  lead-time <= 30 min
    for CheckoutConversion
  }
}

-- enabling teams hold time-boxed powers inside the team they are helping
use org.Delegation(
  from    = SecurityEnablement.persona,
  into    = StreamAligned,
  expires = 6 weeks
) as Embed
  • Team APIs are contracts. Checkout's requirement is met by the platform's offered Deploy. If the platform's lead time degrades past 30 minutes, Checkout's requirement stops being satisfied and a gap opens with an owner, before anyone files a ticket.
  • Enabling teams are temporary. Their power inside a stream team is time-boxed; after six weeks, their acts there misfire.
  • Complicated subsystems are ordinary scopes whose positions require specialist qualifications as eligibility claims.

Enterprise SaaS with compliance

Enterprise SaaS with compliance and customer contractsHalcyonEngineeringSecurity & GRCCustomersAuditorexternal partyTeams×6CAB5 votersCISOGRC analystEvidencecollects controlsprogramAcme DPAEU residencyGlobex MSA99.95 % SLA
Enterprise SaaS with compliance and customer contracts.
Text description of this diagram
  • Halcyon
    • Engineering
      • Teams — ×6
      • CAB — 5 voters
    • Security & GRC
      • CISO
      • GRC analyst
      • Evidence — program, collects controls
    • Customers
      • Acme DPA — EU residency
      • Globex MSA — 99.95 % SLA
    • Auditor — external party

Once enterprise customers arrive, contracts and controls become part of the organization. Each customer agreement is a contract scope with its own obligations. Security and GRC own controls, and a program collects the evidence auditors ask for, continuously.

halcyon.eskesk
scope AcmeDPA : org.Contract in Customers {
  persona AcmeDPAP

  norm Residency {
    prohibition on any Party
    aim exists x : Entity . x is cu.AcmeData
        and custody-jurisdiction(x) not in { EU }
    source external acme.DPA # "§4.2"
    level constitutional   not tradeable   not defeasible
  }

  norm BreachNotice {
    obligation of SecurityGRC.CISO to acme.Party
    when holds sec.breach(x) and x is cu.AcmeData
    aim within 72 h: occurred assert(sec.Notified(acme.Party, x))
  }
}

use org.SegregationOfDuties(
  act      = authorize execute(eng.Deploy, c),
  subject  = eng.Change,
  separate = { c.author }
) as NoSelfDeploy

norm ControlEvidence {
  obligation of SecurityGRC.Evidence to persona
  when occurred tick(t) and t.boundary = "day"
  aim within 4 h: occurred derive(grc.ControlStatus(_, t.day)) by SecurityGRC.Evidence
  not tradeable
}
  • Customer terms become rules. A data-processing agreement's residency clause is a constitutional, non-tradeable prohibition with the contract as its external source.
  • Segregation of duties is checked, not audited after the fact: an author's authorization of their own change misfires.
  • Audit evidence is a by-product. Because the log is the only state, the evidence for an access review or a change-management control is a projection, and a program derives it daily.

Other common variations

VariationHow it's expressed
Remote-first, follow-the-sunRegional positions whose eligibility and routing read a calendar claim; handoff obligations at shift boundaries. See incident response.
Open-core with community maintainersA Community scope admitting external parties; a counts-as rule turning a signed contributor agreement into a grant; maintainers' merge power limited to the open repositories.
Marketplace with third-party vendorsA contract scope per vendor; vendors offer capabilities; their claims start at N and are corroborated by your own monitors.
Holacracy-style circlesScopes with a circle lead position, governance powers at collective level, and roles as positions any member may occupy by election.
Agency or professional servicesA project scope per client with an attention budget; utilization targets as soft intents; change orders as reviewed proposals.