A company run on governed agent work00·18
Delegate to agents.
Keep the decision.
Osalk is the operating layer for a company run by one founder and a team of AI agents. Work is delegated inside declared goals and boundaries, proven by evidence, and accepted or returned by a gate that is never the agent that did it — and when a capability stops fitting, the workspace adapts under governance, not silently.
statebacklog/ready/in-progress/review/done/
Flip Phase-2 policies warn to fail + CI invariants
✓ evidence attached — a reviewer accepts or returns, never the executor
Repository counts are derived from the recorded state. The runtime figure is a priced-token estimate, not billed spend; its period and attribution coverage are stated in the runtime section.
The operating layer for a company run by one founder and a team of AI agents — delegation inside declared boundaries, evidence over claims, and a gate that is never the agent that did the work.
Solo founders and small teams that want to run real work on agents with a recorded, auditable process — before hiring headcount.
Forty days of recorded operation and 744 accepted tasks, run this way in this repository. Five founders are onboard as early design partners.
The problem01·18
You can run a company on agents. You just cannot check their work.
Four failures, each attested by a real operator — sourced from the demand research, quoted verbatim. These are the patterns the system below is built against.
It acts outside its remit, and nothing records why.
“the agent sometimes attempts actions it shouldn’t, and there’s no clear audit trail of what it did or why.”Ask HN · news.ycombinator.com · fetched 2026-10-09
The instructions are suggestions, not constraints.
“Rules behave as suggestions, not fail-closed constraints.”niche forum · operator report, 10+ agent sessions · fetched 2026-10-09
Nobody can attribute the action — or the cost.
“Agents, in most cases, impersonate the human operator, by design, with no way to enforce, disclose, or control it.”Ask HN · news.ycombinator.com · fetched 2026-10-09
The blast radius is whatever the credentials allowed.
“I really don’t want them using this same role when working with AI agents, as I’d like to limit the agents’ blast radius.”r/devops · fetched 2026-10-09
Agents without governance produce demos. Companies need receipts.
Cycle A — verified work, in three rules02·18
Three rules. That is the whole system.
An agent may only touch what its role declares. The permission is a file in the repository, not a promise.
Done is a type, not an adjective: tests pass, artifacts exist, records are written — never that an agent says so.
Work is accepted or returned by someone who is not its author, and the verdict is recorded as a commit.
Osalk does for a company’s work what a ledger does for its money: every task has an author, a scope, an evidence trail, and a verdict that somebody else signed. One task, one worktree, one record — everything else is implementation.
Cycle A — verified work03·18
Two gates. Neither one belongs to the agent doing the work.
progress review done gate 1independent
reviewer gate 2independent
reviewer feedback
→ executor ✓ approved ↩ returned ✓ approved
returned — the reviewer sends the spec or the evidence back
Work moves through five states, and no agent moves its own work through both gates.
A task starts as a written spec with acceptance criteria. Before any work begins, an independent reviewer approves that spec or returns it — this is Gate 1, and it is why a task cannot quietly change shape while it is being done.
When the work is submitted, a second independent reviewer accepts the evidence or returns the task — this is Gate 2. “Done” is not an opinion. It means the tests pass, the artifacts exist and the records are written, and someone other than the executor has checked.
A task that reaches done/ has proven that task’s own acceptance criteria. It is not, by itself, proof that the larger initiative’s outcome landed — a delivery unit passes its own scope review, run by a reviewer independent of its members.
An agent never grades its own homework.
The real board, not a mock-up. States and gates as enforced by the repository.
as folders on the registry branch: tasks/backlog tasks/ready tasks/in-progress tasks/review tasks/done
Accountability — who controls what04·18
Five lanes. Every handoff is recorded.
| lane | backlog | ready | in progress | review | done |
|---|---|---|---|---|---|
| Founder | sets direction | approves high-risk | — | — | — |
| Chief of Staff | writes the spec | claims as reviewer of shape | assigns | — | — |
| Lead agent | — | — | executes in an isolated worktree | submits evidence | — |
| Independent reviewer | — | Gate 1 | — | Gate 2 | closes |
| Git | — | branch created | commits on the task branch | — | merged to the integration branch |
Each lane has a defined role and place in the board. The permission matrix documents each role’s intended read/write scope; it does not by itself demonstrate runtime isolation. The reviewer is never the executor, and never the same identity.
The permission matrix lives in the repository, so “what is this agent allowed to do” is a question with a written answer.
Five boundaries. They are not interchangeable.
Scope means something different at every layer. Each control below is labelled by what the evidence supports: implemented — the mechanism exists in the repository; checked — a hook, CI job or named gate verifies it mechanically; planned — designed, not built; not established — the field exists but no rule yet defines its semantics.
| boundary | what it bounds | status |
|---|---|---|
| goal scope | Every task answers which goal, project, milestone or initiative it serves — work does not exist in a vacuum. | implemented checked membership listing is machine-checked for unit members; for standalone tasks the goal link is a convention, not a gate |
| delivery-unit scope | An initiative, project or milestone has its own in/out boundaries and its own plan and outcome reviews — separate from any member task’s gates. | implemented membership is machine-checked; the scope-gate verdicts are a review procedure with a designated independent reviewer — not a hook |
| task scope | Each task declares what it does and explicitly does not do, plus measurable acceptance criteria, before it may start. | implemented checked required at record creation; Gate 1 reviews it before work |
| touch set | The exact repository paths a task may write — narrower than task scope, declared before ready/ and reserved so no second task edits the same files. | implemented checked machine reservation gate — check_touch_set_reservation |
| role authority | The permission matrix documents each role’s intended read/write scope. | implemented not established role-specific runtime read/write isolation is not demonstrated by the matrix or task-level checks |
Priority, class and risk are three separate axes.
None of them is scope. Priority orders the queue, class sizes the process, and risk — with the external and taste flags — decides who reviews.
| axis | what it decides | status |
|---|---|---|
| priority high · medium · low |
Queue order — what is handled first. It does not set the reviewer tier. | implemented not established the field exists on every record; the per-level meanings are draft proposals awaiting founder approval, not policy |
| class simple · standard · complex |
How much process the work needs — planning and decomposition, and the usual verification tier. | implemented tier routing is a documented convention applied at gate assignment |
| risk + flags low · medium · high · critical · external · taste |
How bad a wrong result would be, whether output leaves the workspace, whether judgment is subjective — together they decide who reviews: machine checklist, independent agent, or human. | implemented checked flagged work routes to the human founder at both gates |
Cycle B — controlled capability change05·18
A signal is evidence. A person decides.
The workspace watches its own capabilities the way it watches work. An observation — a gap, an overlap, a capability that stopped earning its place — is recorded as a signal row. A signal is evidence, never a decision: it becomes a proposal, a designated reviewer decides, and the outcome is recorded. Nothing rewrites itself — learning here is a recorded process, and no run makes the system smarter on its own.
The paths a task may touch, declared before it starts.
→ tasks/ — the touch_set: field on every recordWhat was actually done — one measured block per acceptance criterion.
→ tasks/ — the ## Evidence to submit section’s ### AC blocksAccepted or returned by a reviewer who is not the author — the move is a commit on the records branch.
→ registry — the chore(tasks): gate 2 commits, reviewer-authoredWhat the run cost, measured from the session transcript — never asserted.
→ scripts/reporting-metrics/task_cost_attribution.pySignals are measured, not felt.
- S1The same kind of work done ad hoc ≥ 3 times with no reusable procedure
- S2≥ 2 Gate-2 returns for the same missing procedure or criterion
- S5The same founder question asked more than twice in a short window
- S8Zero selection events across 4 consecutive weekly censuses
- S9Description overlap Jaccard > 0.25, and both selected for the same task class
- S10A > 250-line size alarm held across 3 consecutive censuses with no outcome gain
- S11A role with zero executed tasks over a rolling 4-week window
- S12Rerouted away from on > 10% of runs in a census window
Any agent may append a row the moment a signal fires — a row is evidence, never a decision; a filed proposal still decides.
→ .agents/capability-signals.md · docs/foundation/graph-skill/spec/12-capability-gap-signals.mdEvery decision lands on one of five recorded outcomes.
- no-changeReviewed and deliberately left alone — a recorded “no”, not silence.
- addA new role or skill is built only after an approved proposal.
- updateKept, but its definition is corrected — re-described or re-scoped.
- narrowIts surface is reduced or merged — overlap narrowed, size remediated, or two folded into one.
- retireDeprecated first; a tombstone row records why; reinstatement stays open through a 4-week grace; deletion is a second, separate act — human-gated throughout.
Measured, never invented. Where usage cannot be counted, the capability census records the fact as unknown — its own words:
“→ scripts/reporting-metrics/capability_health.py — the capability censusunknownis distinct from0: a capability absent from every committed usage source recordsusage_count: null, never0”
Sensingrunning today
Signals, thresholds, gate verdicts and per-task cost — read off the same board that ships this page.
Standingplanned
What a capability has earned, read back from the outcomes on record — nothing awarded that the record cannot show.
The loopplanned
A task proposes a change to a role, a skill or a process — then travels the same two gates as every other task.
The loop is not new. The accountability is.
Published agent-improvement loops diagnose and hand back a dashboard. This record answers the question a founder has to answer instead: who accepted the change, on which evidence — and can it be undone.
Proof — internal dogfooding06·18
One real task, taken verbatim from the record.
This is the record of TASK-2026-784 — internal dogfooding: the founder-run workspace applying its own operating model to its own company work. It is not customer traction, not a pilot, and not external adoption. What it shows is the gate working: a submission returned once, fixed, and accepted by a reviewer who was not the executor.
gate verdicts on this task: gate 1 — approved gate 2 — returned once gate 2 — accepted reviewer ≠ executor
A gate that only ever says yes is not a gate. This one rendered the work, caught what the paint did not show, and sent it back.
Read the complete record — spec, evidence, the Gate-2 return, the acceptance →
Watch one task go through both gates — live on a call, unedited →
What the market is missing07·18
Governance is what makes agents deployable.
Agents are already capable enough. The reason they do not run a company’s work is that nobody can audit what they did. Least-privilege permissions, audit logs and access control are table stakes — enterprise vendors ship them, and audit logs are a priced line item. What the analysts and the auditors say is missing is governance end-to-end across the whole work lifecycle, and evidence produced rather than asserted.
Forrester, 27 August 2026
“No single vendor currently provides end-to-end agent governance” — “the organization receives a capability boundary and a set of claims about behavior but no evidence of how that behavior is produced.”
Source: Forrester, 27 Aug 2026Microsoft’s own guidance
“identity, scope, tool access, and auditability must be defined before autonomy expands” — and the same page’s pattern is to “Separate read role (evidence gathering) from write role (ticket creation).”
Source: Microsoft agent-governance guidance · original publication date not recordedThe auditors’ numbers
Only 13% of organisations say their identity and access controls are adequate for agents (Gartner, 2026-04-28). 68% cannot reliably distinguish agent activity from human activity in their own logs, and only 28% can trace an agent’s action back to a responsible human (Cloud Security Alliance).
Sources: Gartner, 2026-04-28 (read via syndicated reprints — the press page returns 403); Cloud Security Alliance researchFor Osalk, the unit of accountability is the task: its declared scope, submitted evidence and independent verdict stay together in one record.
Maturity08·18
What runs today, what is coming, and what is only an intention.
A roadmap is not a feature. Everything below is labelled by what it actually is, and every “in production” row names where it lives in the repository.
| tier | feature | where it lives |
|---|---|---|
| in production | Two-gate task governance | docs/foundation/rbe/ |
| in production | Evidence-over-claims completion | the Gate 2 contract · docs/foundation/rbe/ |
| in production | Documented role permissions; runtime isolation not established | docs/foundation/framework/permissions.md |
| in production | One task = one isolated worktree | scripts/worktree/ · .worktree/config.md |
| in production | Nine agent roles · 29 skills · 49 hooks | .agents/ · .agents/skills/ · .pre-commit-config.yaml |
| in production | Per-task cost attribution for the current runtime | scripts/reporting-metrics/ |
| in production | Eval program with recorded pass rates | evals/ · 1,367 files |
| in beta | Dependency-aware fleet dispatch | scripts/fleet-engine/ |
| in beta | Demand-signal radar | knowledge/signals/ |
| in beta | Trust ledger and KPI layer | docs/foundation/ — wiring in progress |
Nothing below runs today. Each line names what it would change. None of it is described in the present tense.
next make the gate fast enough to actually read.
A gate nobody reads is not a gate. Each line would change how long a verdict takes — not what it proves.
| tier | feature | where it lives |
|---|---|---|
| planned | Evidence bundle rendered as one reviewable page | planned — extends evidence |
| planned | Evidence diff between a returned submission and its resubmission | planned — extends evidence |
| planned | Exception queue — the single list of human decisions | planned — extends gate |
| planned | Cost attached to the verdict that closed the work | planned — extends evidence |
then make the verdict carry the money.
Cost without a value is half a business case.
| tier | feature | where it lives |
|---|---|---|
| planned | Value per task against a recorded human baseline | planned — extends evidence |
| planned | Cross-run agent performance analytics | not yet |
| planned | Portable audit export for a period | planned — extends gate |
later make the boundary enforceable.
Published agent-improvement loops diagnose. Almost none can act safely, and none records who accepted the change. The loop is not new. The accountability is.
| tier | feature | where it lives |
|---|---|---|
| planned | Scope as an enforced contract, failing closed | planned — extends scope |
| planned | Blast-radius preview before a task runs | planned — extends scope |
| planned | Delegation-safe scope — no token inheritance down a sub-agent chain | planned — extends scope |
deployment your data never leaves.
The control plane may be hosted; the execution plane — the agents, the repository and the API keys — stays in infrastructure the customer owns.
| tier | feature | where it lives |
|---|---|---|
| planned | Control plane hosted, execution plane in the customer’s own infrastructure | not yet |
| planned | Company-in-a-box onboarding | not yet |
| planned | First-party API integration in a customer-owned provider account | in progress — not in use |
| planned | Multi-tenant fleet scheduling | not yet |
The rule the roadmap is held to: if a feature cannot be stated as a change to scope, evidence or gate, it is not part of the product.
Honest limits09·18
What we do not claim.
- No users. No revenue. No launched product. No SOC 2.
- First-party API use through Osalk’s own Console organisation: no calls have been recorded yet.
- No customer logos and no testimonials — because there are none yet.
In a market measured by what vendors promise, the record of what ours actually did is the product. We would rather hand you that than a logo wall.
What exists today10·18
An organization, not a chat window.
What runs in this company today — roles, gates, permission policy and evidence, as one system. Capabilities range from production to beta; each row labels its maturity or documented-policy status and names where it lives.
Nine specialised agent roles in production
CEO, Chief of Staff, Tech, Sales, Marketing, Support, Research, Reviewer, Radar Ops — each with a defined mandate.
A governed task board in production
Work moves backlog → ready → in-progress → review → done, with independent two-gate review.
Least-privilege permissions documented
The repository documents intended read/write permissions by role. Runtime enforcement of that matrix is not established by the evidence shown here.
Evidence over claims in production
“Done” means tests pass, artifacts exist, records are written — verified, not asserted.
29 procedure packs in production
The skills each agent loads before acting — task ops, review, research, git workflow.
49 governance hooks in production
Checks that run before a commit and in CI — identity, scope, language, records integrity.
Per-task cost attribution in production
Usage is attributed only when the records support a task match; unmatched usage stays visible rather than being spread across tasks.
Demand-signal radar in beta
Agents mine communities and job boards for what customers actually ask to pay for.
Dependency-aware fleet dispatch in beta
Batches of tasks dispatched to parallel agent workers, each in its own worktree.
Provider-neutral definitions in production
Provider directories link to the canonical definitions. Repository checks validate those links, not runtime compatibility or equivalent behavior.
Nine agent roles. Twenty-nine skills. Their definitions and procedures are versioned in the repository; task scope and independent review govern delivery.
Least privilege, in writing.
The permission matrix documents each role’s intended
read/write scope. The check-scope hook checks task-staged
files against the declared touch_set; it does not enforce
the role matrix or establish runtime read isolation.
Open the full permission matrix — role by directory
| role | codebase/ | knowledge/ | .agents/ | shared-drafts/ | approvals/ |
|---|---|---|---|---|---|
| CEO | read · review | write all | write | write | write · approve |
| Chief of Staff | — | read all | read · notes write | write | read · file pending |
| Tech Lead | write | write eng · read rest | read | write | read related |
| Sales Lead | — | write sales · mkt · product | read | write | read related |
| Marketing Lead | — | write mkt · product | read | write | read related |
| Support Lead | — | write support · product | read | write | read related |
| Research Lead | — | write all | read | write | read related |
| Radar Ops | — | write signals · product | read | write | read related |
| Reviewer | read · review | read all | read | read | read · file pending |
| Founder | all — the founder is the only merge into the product branch | ||||
writeread onlyno access
Cells derived from docs/foundation/framework/permissions.md — the file the roles read.
Architecture — for the technical reader11·18
Your company’s operating state is a repository you can diff.
Agents do not share a working directory, and the state is in git — so history is auditable rather than narrated: what changed, when, by which identity, and which task authorised it. The layers and the worktree topology are depth, not storyline — they fold open below.
Open the architecture — layers and worktree topology
Agent definitions
one canonical file per role, provider-neutral
Skills
the procedure each agent loads before acting
Governance hooks
the checks that run before a commit
Delivery surfaces
develop (product) · history (decisions) · registry (records)
.worktree/
TASK-2026-098
.worktree/
TASK-2026-727
.worktree/
TASK-2026-805
.worktree/
TASK-2026-779×
branch gate
founder
Each task gets its own git worktree and its own branch, so two agents cannot overwrite each other and a failed task cannot contaminate a working one — a branch that never reaches the rail is a branch that never landed.
Operating model — current runtime disclosure12·18
Your operating rules belong to your company.
Osalk keeps roles, permissions, task records and review rules in the company’s workspace, not within one provider. The internal workspace currently runs through Claude Code. Adapter checks confirm configurations map back to canonical definitions; they do not prove identical runtime behavior or universal support.
latest recorded procedure evaluation: mock_mode: false passed 3/3 evals/results/task-ops-2026-09-10.json
Evaluations describe a run, not every provider
The latest recorded procedure evaluation passed 3/3 with mocks disabled. That result describes one run; it is not a cross-provider performance claim.
→ evals/results/task-ops-2026-09-10.jsonUsage is a priced-token estimate
~$859 at list rates across 26,685 turns in one measured window — not billed spend. 18.0% ($154.36 across attributed tasks) resolves to a task; $704.72 across 22,764 turns remains unattributed and is reported separately.
→ docs/foundation/test/measurements/cost-kpi-2026-09.mdAttribution stays evidence-bound
Where usage records support a task match, cost can be shown beside that task’s evidence and verdict. Unmatched usage is not distributed across tasks.
→ scripts/reporting-metrics/task_cost_attribution.pyThis is internal dogfooding: the founder-run workspace uses the operating model on its own company work. It is not evidence of external customer adoption.
First-party API status. No API calls from Osalk’s Console organisation have yet been recorded. The usage evidence above describes internal agent runs, not first-party Console API use.
→ API-use evidence is pending TASK-2026-768; usage snapshot: cost-kpi-2026-09.mdWho it is for13·18
Founders who want leverage, not headcount.
Solo founders & indie hackers
You want to run a company with one pair of hands and a record of every decision, so you can step away for a week without losing the thread.
Small teams
You are trying agentic operations before you hire, and you need process discipline that scales before the org chart does.
Builders & researchers
You are evaluating how far a one-person company can scale on AI agents, and you want auditability to be the control variable rather than a slogan.
The ask14·18
Try it on your own company. Or support the build.
Both start with the same email to the founder. The primary path is a design partner: founders run a working session on their own repository — a controlled pilot, not a demo. The secondary path is non-dilutive support — acceptance into startup-support programs and in-kind resources. No amount, no instrument, no runway figure, no guaranteed credit appears on this page; where terms exist, they live with each program.
Apply as a design partner
Apply for a working session on your own repository. Osalk is not a self-serve product; a design partnership would let both sides test whether the operating model fits. Five founders are already onboard as early design partners — across workflow automation, AI media, marketing ops, finance ops and customer support. Exchange terms remain a founder decision, marked pending rather than invented.
What a supporter gets
A real user running its own company on a governed agent team — and a verifiable build story: records, gates and evidence a reviewer can inspect, not a deck of asserted traction.
What support buys
Resources that extend the build — program credits, in-kind tooling and placements — while the founder keeps strategy, approvals and final decisions. Support does not buy a stake.
The honest version of this ask: what exists is a working governed system and the records that prove it. A design partnership would test the operating model against another company’s work; non-dilutive support would help extend the build.
Intake15·18
Write to the founder.
Two conversations start at the same address — apply as a design partner to run your own company this way, or offer non-dilutive support (programs and in-kind resources). Either way, both go to the same inbox.
Route status — verified live. The founder@osalk.com mailbox is provisioned at the domain level (MX and SPF live), and a founder send/receive test landed on 2026-10-13. No response time is promised.
- the founder intends to answer every message that arrives — no response time is promised
- one short call to see whether it fits
- no card, no terms on this page — there are none to accept
Vinh Le — founder, Osalk
One operator and the governed agent team this page describes. The founder sets direction, keeps approvals and final decisions, and intends to answer every message that arrives — including yours.
FAQ16·18
Two kinds of questions.
Practical questions — five short answers
Is Osalk available today?
Not as a self-serve product. We are onboarding a small number of founders directly, one at a time. That is what early access means here.
Is Osalk tied to one AI provider?
No. Osalk’s operating rules, tasks and evidence are defined independently of a provider. Adapter checks confirm each tool points to the canonical definitions; they do not establish equal runtime behavior. Integration support is explicit, not assumed.
Where does my data live?
In your own repository. Osalk governs how work is done; it does not take custody of your operating state.
What does it cost?
Pricing is not set — and the early-access offer itself is a founder decision still open, so this page marks it pending rather than inventing terms.
What is the catch?
We are early. Some of what is on this page is in production, some is in beta, and some is planned — the section above labels which is which.
The honest questions.
Are you raising money?
Not on this page. The ask here is non-dilutive support — acceptance into startup-support programs and in-kind resources that extend the build. No equity, amount or terms are offered anywhere on it; an investment conversation would need its own framing — and qualified review — before it appeared here.
Are your gates binding, or are they promises the agent makes to itself?
Both — and the honest part is knowing which is which. The load-bearing rules are code: hooks and CI gates that refuse a commit when the schema, the evidence, or the approval is missing. The judgment rules still live in prose, and we treat that as debt — most of this repository’s history is a trail of converting rules agents broke into checks agents cannot skip. That is also what separates this from just using a coding agent: a coding agent produces output; this produces output that someone other than the author has accepted, inside a recorded boundary of what was allowed.
If my executor and my reviewer are the same model, is the review actually independent?
Independent in mechanism — the reviewer never executed the task, never saw its context, and is scored separately when a later audit catches what it missed. Independent in capability? Honestly, no: the whole org runs on one model family today, and two instances share blind spots. That is why high-risk work routes to a human regardless, and why the definitions are provider-neutral — review can move to a different model the day that becomes the better answer.
What has an agent done that you only found out about later?
The failure mode is documented across the industry: an agent holds a foreground process for hours, or overwrites a file nothing was watching, while the board still shows green — because boards show what agents report. The structural answer here is that work only counts when it lands in git; an action with no commit produced no deliverable, and audit sampling exists for what the reports do not say. Every hole found in this repository so far has become a rule or a check.
Who writes the rules the agents follow? The agents do.
The same answer as every other change here: a governance edit is a task — it passes scope review, gets executed, passes independent review, and anything sensitive lands in the human’s approval queue. Agents draft the rules; they do not get to enact them alone. The recursion is real, which is why the human never leaves the loop that edits the loop.
When an agent acts in the company’s name, can the audit trail survive a dispute?
Our working assumption — a design choice, not a legal claim — is the one this system was already shaped around: the deployer owns the act. So every consequential action traces to a named human decision — an approval file, a timestamp, a scope — inside immutable git history. Whether that satisfies a courtroom is genuinely untested; multi-agent liability doctrine does not exist yet. What exists is a record designed to be read by one.
The human gate assumes I’ll actually read the evidence. Won’t I rubber-stamp by the hundredth approval?
Probably, some days — automation bias is real, and we would be lying to design around a founder who never gets tired. So the approval brief is built for a tired reader: a yes/no decision, the options, a recommendation, an expiry. And nobody grades the human — deliberately. The ledger measures agents; your judgment is the ceiling the system defers to, including the day you stamp without reading.
Is the whole company really run this way?
Yes, and it is the reason this page exists: the same board, gates and evidence rules that ship this company’s work also produced this site.
Start here17·18
Evidence over promises. People keep the decision.
Design partnerships and non-dilutive support both start with one email to the founder.