Plastic Labs — Operating Model
Status: Draft for team review | Owner: Vineeth | Last updated: 2026-07-13
How we plan, own, and ship. The pillar re-cut and the Q3 Product + Platform deliverables are already live in Linear (Phase 1 + Phase 3 executed 2026-07-13); this doc is the durable description + the open decisions still on the table. Decision trail: decisions log.
Why we’re doing this
The team is ~10 engineers and we’ve outgrown “check in on people occasionally and assign tasks ad hoc.” Linear today is a system of record (backlog capture) but not a system of intent: it can’t answer what’s the priority, who owns what, what’s blocked on what, what ships this quarter, is it on track. The root cause is evergreen projects — long-lived buckets (Storage API, Deriver, Eevee) that never complete, so they can’t express priority, a target date, or “done.”
Goal: a roadmap the ICs actually plan against — ownership, sequence, review chains, rough deadlines, and “what to pick up next.”
The model: pillars → deliverables → sprints
| Layer | Linear object | Rule |
|---|---|---|
| Pillar | Initiative (durable) | Stable area of the org. ~4 technical + Growth. |
| Deliverable | Project | Completable, has a lead + target date, scoped to ≲1 quarter. No evergreen (one exception: maintenance lanes). |
| Sprint | Cycle (2 weeks, shared cadence) | Execution unit. |
| Roadmap | Linear roadmap view over target dates, grouped by pillar | Derived from execution, never hand-maintained (that’s what rotted the old roadmap). |
The wiki holds slow-changing things (this doc: ownership, review chains, conventions). Linear holds fast-changing state (what’s happening). That division is what stops staleness.
flowchart TD Q["Quarter plan (3 mo) — Linear roadmap view"] --> PR["Product"] Q --> PL["Platform"] Q --> RE["Research"] Q --> SP["Side-Projects"] PR & PL & RE & SP --> D["Deliverables (completable projects: lead + target date)"] D --> C["2-week cycles (sprints)"] C --> S["Weekly all-hands standup"] MAINT["Per-pillar Maintenance lane (evergreen exception) + capacity reservation"] -.feeds.-> C
Pillars
Five pillars — four technical + Growth. Growth/PLG runs the same operating model (initiative → dated deliverables → backlog-as-status), but it’s a separate team (GRW), mostly separate people, and its own cadence (Wednesday sync). So the altitudes split: the company roadmap and org-level status span all five pillars, while the operational boards — by-assignee, flow, WIP — stay per-team. Don’t merge Growth into the engineers’ boards (different work, different cycles); combine only at the roadmap/status layer.
| Pillar | Lead | People | Scope |
|---|---|---|---|
| Honcho / Product | Vineeth | Aakash, Eugene, Eri (integrations/FE), Abigail (docs/demos) | Core harness: Storage API, Deriver, Dialectic, Dreaming, SDKs, CLI, 3rd-party integrations, docs/demos, Hermes |
| Platform | Rajat (Ulysse, Phil) | Groudon, Xatu, model serving (Metagross), eval/serving infra (Excadrill/Eevee runtime), Dev-Experience/automation | |
| Research (ML) | Matt / Yuya | Deriver conclusion quality (ML-335), dreaming investigations, benchmarks, training runs (Machamp), Neuromancer | |
| Side-Projects | per-project | Kyogre, YouSim, Dedenne, Mimikyu, Honcho Demo UI — each carries an active / parked status + a named owner | |
| Growth / PLG | growth team (Abigail liaison) | PLG, ads & narrative, content, landing/site, neocloud BD (“Honcho in Space”) — separate GRW team + Wednesday cadence; same model, its own boards |
Intern + Vineeth float across pillars (startup — anyone can work anywhere; pillars organize the work, not cage the people).
Platform ↔ Research boundary (infrastructure vs. instrument): Platform owns the runtime (model serving, the eval harness as runnable/cheap/reliable infra — e.g. ML-330 “bench too expensive” is a Platform problem). Research owns the instrument logic (bench design, prompts, scoring, experiments). Consequence: ML-335 stays in Research but takes a dependency on Platform’s harness work. Excadrill and Eevee live in both initiatives (Platform + Research) — Linear projects can belong to multiple pillars, matching the shared operational reality.
Product prioritization principles
Seven axes guide what Product invests in — six expansion axes plus the foundation beneath them. Ownership below is the current lean, not fixed; people move between axes as work lands (CloudEvents + Scopes finish soon, freeing Aakash / Vineeth).
- Visibility — understand how Honcho is actually used. CloudEvents, tracing, telemetry. Lean: Aakash.
- Memory quality — a better memory agent through harness engineering. Dreaming, eval climbing, dialectic. Spans Product × Research — Research measures, Product improves (Eugene moving toward intersectional research+product; Matt/Yuya on the eval side).
- Developer experience / topologies — fit cleanly into as many application architectures as possible. Scopes, SDK, composable peers, CLI. Lean: Vineeth + Abigail (CLI).
- Expanding the substrate — widen what Honcho can ingest and represent. Headline bet: make Honcho native for CLI / coding agents — model a codebase as its own peer, add a filesystem primitive (coding agents keep local notes), push toward Honcho as a “company brain.” Also multimodal + non-conversational data. Currently unstaffed — the deliberate next bet to pick up as capacity frees.
- Groudon UX — make it easy to see and interact with what Honcho is doing. Tabbed shells, Groudon assistant. Lean: Eri (+ Aakash supporting).
- Ubiquity — make Honcho the most ubiquitous piece of the stack: reachable in whatever form a developer already works in. Third-party integrations, self-hosting accessibility, the inference gateway, alternate vector-DB and inference backends, local-run defaults. This is the axis the open-source-first shift (2026-07-27) feeds: self-hosting stops being a second-class citizen. Distinct from axis 3 — axis 3 is leverage (one SDK change improves every integration, and the set converges), ubiquity is surface area (each integration carries its own maintenance tail, and the set only grows).
- Foundation / reliability (the base under all six) — trustworthy in production: reliability, performance, cost (toward the $2/M input-token target). Connection/concurrency hardening, deriver/queue scaling, and the data-model migration — first-class tree-of-conclusions & tagging;
Collections→representations,documents→conclusionsrenames, as a coordinated breaking release gated on Groudon. Platform takes point on reliability items as they arise. Reliability / data-model work may be dual-listed across the Product + Platform initiatives — a project can belong to both.
Tie-breaker when axes compete: design-partner-driven → unblocks-other-axes → cost-toward-$2/M → net-new capability.
Open question (2026-07-27): the tie-breaker doesn’t yet account for reach. Ubiquity work loses on all four clauses — an integration is rarely design-partner-driven and isn’t net-new capability. If ubiquity is genuinely this chapter’s goal, the tie-breaker needs a reach clause or ubiquity will keep getting voted down by a rule written before it existed.
Integration work: build vs. maintain vs. improve
Integration and reach work splits three ways, and the axis follows what the work is, not which artifact it touches:
| The work | Axis |
|---|---|
| New reach — a host, architecture, or deployment mode Honcho didn’t previously touch | ubiquity |
| Keeping it working — version bumps, community bug intake, upstream breakage | none — evergreen lane |
| Making it better — improving an existing integration’s quality | the axis matching what kind of quality is improving |
That third row is the one people get wrong. claude-honcho v2 is memory-quality, not ubiquity — Claude Code integration already exists, and the work is about injection relevance, actor attribution, and context quality. Another integration’s improvement might land on dx-topologies or foundation instead. Label the work, not the thing.
This composes with the per-integration rule (2026-07-15): every integration gets a scoped build project (→ ubiquity) and a scoped maintenance project with clear intake (→ untagged).
Consequence to accept knowingly: a project can change axis over its life — ubiquity while being built, then memory-quality during a later quality push. Linear allows one axis label, so that’s a re-label, not a conflict. Axis labels describe current intent; cycle records and status updates carry the history.
How axes are recorded in Linear
Each axis is a project label: visibility, memory-quality, dx-topologies, substrate, ubiquity, groudon-ux, foundation. Each label’s description says what belongs in it — read it before tagging.
- Projects only, one axis each. An issue’s axis comes from its project, so issues are never tagged directly. The six labels are a group, and Linear enforces one per project — a second is rejected outright, not silently added. Plenty of projects genuinely touch two (embedding models is quality and cost); pick the primary and mention the other in the summary, the way “Axis 6/3” does.
- Don’t tag evergreen lanes or container projects (Docs/Demos, a monthly cleanup). They aren’t portfolio bets, and tagging them makes every capacity-by-axis count misleading.
- No axis is the right answer sometimes — GTM and demo work usually belongs to Growth, not to one of the six.
- This is a Product frame. Platform, Research, and Growth track their own scope; don’t force their projects onto these labels.
What this buys: “where did our capacity actually go, and which axis got nothing” becomes a filter instead of a reading exercise. That question is the point of the six axes, and it was unanswerable while the axis lived only in prose.
Resolved 2026-07-27: integration work was the open question here. It now has a home — see Integration work: build vs. maintain vs. improve above. Short version: new integrations are ubiquity, maintenance is untagged, and quality improvements take the axis of whatever quality they improve.
Project & backlog rules
- A project must have a nameable done and a rough when. If it doesn’t, it’s not a project — it’s backlog.
- Backlog = a status + holding pen, not an evergreen bucket. Carve the near-term (this quarter+) into completable deliverables; the rest stays backlog.
- Intake: Linear is the source of truth for planned work. OSS repos (honcho, SDKs) take GitHub issues from the community → synced to Linear Triage → triaged into a pillar backlog or deliverable. Internal repos (Groudon, infra) file directly in Linear. The ~20 loose infra repos get one Platform backlog, not a project each.
- Don’t run two backlogs. GitHub issues are an intake channel; Linear owns priority + sequence.
What makes something a project
Backlog + area: tags are the intake; a project is what we commit to out of it. The area tag is how you find a candidate; the project is the commitment. Promote a backlog cluster to a project only when it clears all five:
- Nameable done — the shippable outcome stated in one sentence.
- More than one issue — a cluster/milestone, not a single bug or chore (those stay issues).
- Committed, not someday — shippable within the planning horizon, so it can carry a target date.
- Has a lead.
- Advances a pillar/axis.
Fail any → it stays backlog. Two anti-patterns to refuse: a theme with no committed outcome (“Storage improvements”) is an area label, not a project — minting it as one is the evergreen bucket we’re killing; and a single issue is an issue, not a project (don’t fragment). Promotion happens at planning boundaries — scan the area-tagged backlog, find a cluster that clears the test, give it a lead + target date, and pull the issues in. So we’re never “just doing backlog forever”: the backlog is the quarry, and each quarter we cut dated projects out of it.
Work types & maintenance
Three shapes of work — the roadmap only shows the first:
| Shape | Example | Has done+date? | Home |
|---|---|---|---|
| Deliverable | ”Scopes GA” | Yes | Roadmap |
| Maintenance / KTLO | openclaw still works after their update; dep upgrades | No (recurring) | Per-pillar maintenance lane + capacity reservation |
| Interrupt | prod incident, support bug | No (reactive) | Triage → current sprint |
Mechanisms:
- Label every issue
type: feature | maintenance | bug | chore— so KTLO load is visible and reportable. - Reserve ~20% of each sprint for maintenance/interrupts. Don’t plan cycles to 100% features. Consistently blowing past 20% is a signal to surface, not hide.
- One sanctioned evergreen per pillar — e.g.
Product — Maintenance,Platform — On-call & Upkeep. The only exception to the no-evergreen rule; explicitly a capacity bucket, not a deliverable. Maintenance is not its own pillar — each pillar owns its own. (Note: integrations are not an evergreen lane — they’reintegration:-labelled backlog + promoted deliverables; see Labels.) - Detectors over reminders for reactive checks: a scheduled CI job (or upstream-release trigger) runs integration smoke tests → on failure auto-files a GitHub issue → Triage → the integration’s DRI. “Stay up to date” becomes automatic surveillance; humans only fix real breaks. Deps → Dependabot/Renovate; provider API drift → a canary.
- Building an automation is a deliverable (has an end); the check it then runs is maintenance. Proactive tooling/process work lives in Platform → Developer Experience / Eng-Productivity as dated deliverables.
- Ownership: DRI per integration (openclaw → Eri, etc.) + the 20% reservation. Skip a rotation until it hurts.
Labels & conventions
Use Linear label groups (controlled vocabulary, not free-form):
type:—feature | maintenance | bug | chore | support | incident. Drives capacity reservation + reporting (how much of the sprint is KTLO / support).repo:—honcho | groudon | kyogre | sdk-py | sdk-ts | excadrill | …. Optional planning-time hint. Use when the involved repo isn’t obvious from the project, or the work spans repos. Don’t tag single-repo-obvious issues — a linked PR already surfaces the concrete repo via the GitHub integration.integration:—claude-code | openclaw | opencode | vercel | mcp | sillytavern | hermes | …(under theintegrationparent group). Third-party integrations are tracked by label, not a standing project — the old evergreen “3rd Party Integrations” project is dismantled (label the sub-issues, delete the umbrella epics, browse via a savedintegrationview). Committed integration work (e.g. Claude Code hardening, OpenClaw maturation) gets promoted to a dated deliverable; the rest isintegration:-labelled backlog.- Priority — actually set it (Urgent/High/Med/Low). The audit found it unset workspace-wide.
Projects are outcome-scoped and may span repos; repo: labels + linked PRs answer “what’s happening in <repo>,” so we don’t couple project↔repo.
Support, Community & On-call
Support/community is a continuous, reactive, relationship-driven operational function — not a pillar, and distinct from maintenance (maintenance = our code keeps working; support = serving external people). Decided 2026-07-23: run it as one combined weekly rotation + one Triage funnel, staffed from the dev team — split into two rotations only if volume outgrows one hat. Full runbook: Incident Response & On-Call.
- Combined on-call (Rootly) — the weekly owner carries both jobs. (1) Incidents/pages — prod alerts from Sentry/GCP/Grafana, postmortems; real paging (per-person notification rules escalate push → SMS → phone; the policy escalates Primary → Secondary → all-Platform). (2) The non-paging support/OSS queue — Discord + email Q&A, OSS issue/PR triage, contributor Q&A. Dev-team-staffed; rotates weekly to avoid burnout.
- Intake → one funnel: Discord/email → Linear Triage (support intake); OSS GitHub issues/PRs → synced to Triage. On-call triages: answer/close, or convert to a routed pillar issue (
type: bug|feature). - OSS management is part of the same rotation — not a separate hat. It owns first-response + triage/shepherding of contributor issues and PRs (run the
pr-triageskill at the start of each rotation), labeling good-first-issues, keepingCONTRIBUTINGcurrent. Deep code review still routes to the area reviewer (see review chains) — the rotation owns response & routing, not reviewing every PR itself. - Capacity: the on-call person’s sprint load is reduced — their duty consumes the reservation. The duty itself is
type: support|incident, not a deliverable. Escalations that become real work → normal pillar issues. - What to build (Platform deliverables, dated): Rootly setup, Discord→Linear intake, OSS-triage automation. Building = deliverable; running the rotation = operational.
- Cadence: weekly rotation (aligns with the Mon standup); publish the schedule. Revisit splitting into separate Incident and Support&Community rotations if support volume makes one hat too heavy; promote Support to a full pillar only if it outgrows a rotation.
Cadence & meetings
Three-layer cadence: quarter (3-mo plan) → 2-week cycle (execute) → weekly standup (sync).
| When | Meeting | Who |
|---|---|---|
| Weekly (Mon) | All-hands standup (short) | Everyone |
| Biweekly (sprint boundary) | Research sync | Matt, Yuya |
| Biweekly (sprint boundary) | Platform sync | Rajat, Ulysse, Phil |
| Biweekly (sprint boundary) | Product sync (Honcho + FE + DevRel) | Product pillar |
| Weekly (Wed) | Growth/PLG sync (existing, unchanged) | Abigail + growth |
Cycle setting to change (manual, Linear UI — not API): DEV team cycles weekly → 2 weeks (Settings → Team: Development → Cycles). ML already fortnightly; align start dates so all pillars share sprint boundaries. DEV Cycle 93 ends 2026-07-13 — clean boundary.
Working agreements — WIP limits & review-first
To fight the review bottleneck (we chronically stall on reviews):
- Review-first. Before starting new work, clear the PRs you’re responsible for. Responsible for = you’re a requested reviewer, it’s in your area (see review chains below), or it’s blocking a teammate.
- Finish before you start (WIP limit). Clear your own in-progress code — merge or explicitly park — before opening new work. Target ~1–2 active PRs per person; enforce with a WIP limit on the Linear In Progress column.
Distribute review authority. Review-first only works if reviews don’t all funnel to one person — fill in the per-area reviewers below so Honcho reviews spread beyond Vineeth’s final pass; keep final-pass only where it must be.
Tracking (feeds the workload skill): GitHub is the source of truth for PR/review state, Linear for issue WIP. Surface a per-person review queue (PRs awaiting your review) + my open PRs at standup; the pr-triage skill already buckets “who owes the next reply.”
Workload & review-load skill (Phase 4) — per person, across projects, it should compute:
- Review debt — open PRs where they’re a requested reviewer / area DRI and haven’t reviewed (age-weighted).
- WIP — their open authored PRs (draft + ready + changes-requested) and In Progress Linear issues; flag over the limit.
- Policy violations — new work started while review debt > 0 or WIP > limit.
- Bottleneck — the reviewer with the largest / oldest queue.
- Progress — per-project cycle burndown, stalled issues (In Progress, no PR or no movement in N days), deliverables vs target dates.
Ownership & review chains
| Area | Lead | Primary reviewer(s) |
|---|---|---|
| Honcho core (Storage/Deriver/Dialectic/Dreaming) | Vineeth | Vineeth (final pass), Aakash, Eugene |
| CLI | Abigail | Abigail, Vineeth |
| SDKs (Python / TS) | Eugene / Aakash | Vineeth (final pass), Eugene, Aakash |
| Frontend / integrations | Eri | Eri, Vineeth |
| Docs / demos | Abigail | Abigail |
| Platform (Groudon/Xatu/infra) | Rajat | Rajat, Ulysse, Phil |
| Research (ML) | Matt / Yuya | Matt, Yuya |
Integration DRIs: OpenClaw → Abigail · Claude Code → Abigail · Hermes → Eri · Codex → Eri · Opencode → Adavya · Paperclip → Adavya. (confirm)
Open decisions & TODOs (living)
Decisions pending (mostly for the team meeting):
- On-call model — decided (2026-07-23): one combined rotation (incidents + support + OSS), dev-team-staffed; revisit splitting into two if support volume outgrows one hat.
- Phase 3 structural mechanic — confirm A-refined (deliverables = projects; backlog =
Backlogstatus +area:label; integrations →integration:labels (no standing project); docs/demos stays an evergreen lane for now; archive core area-projects gradually) vs. B. - Fill the review-chains table (SDK/CLI reviewers, per-area reviewers) — load-bearing for distributing review away from Vineeth.
- Committed vs. stretch Product deliverables for Q3 (SDK quality is the current stretch).
- Substrate / coding-agent bet — start this quarter or Q4?
TODOs (owner → next step):
- You (manual): flip DEV cycles weekly→2-week (Linear settings), S1 start Jul 14.
- Create Linear label groups:
type:,repo:,area:. - Execute Phase 3 in Linear after the team review (create deliverable-projects, move scheduled issues, assign cycles, gradual area-project archive, cleanup pass).
- Build the two skills: audit-Linear state + workload / review-load (reuse
pr-triage). - Stand up the OpenClaw detector (first automation deliverable, Platform).
- Platform pillar carve (folds in DEV-1971 PII filtering + the data-model migration under Foundation).
- Research pillar carve — after end of July (team heads-down on dreaming/deriver investigations).
- Data-model migration (Collections→representations, documents→conclusions; first-class tree-of-conclusions & tagging) — schedule once Groudon unblocks; coordinated breaking release.
- Write the codebase-as-peer spec (net-new; substrate axis).
- Move these planning docs from repo root →
wiki/content/engineering/once settled. - Cleanup pass: close 6 Duplicate-state issues, re-file DEV-844 / DEV-1781, update the sdk-improvements spec.
Execution plan (what changes, in order — pending your approval)
Phase 1 — Re-cut initiatives — ✅ EXECUTED 2026-07-13 (Platform e50a1fc0 · Side-Projects b4a215fa · Honcho/Product 5a8656e6 owner=Vineeth · Research (ML) a14f9224 owner=Yuya · Platform owner=Rajat · Demos archived · 16 projects reassigned):
- Create initiatives Platform and Side-Projects.
- Repurpose “Honcho” → “Honcho / Product”; repurpose “Evaluation Benchmarks” → “Research (ML)“.
- Reassign every active project to its pillar (per the Pillars table); set Vineeth as Product lead, Rajat as Platform lead, Matt/Yuya as Research.
- Leave Growth/PLG (Honcho in Space) untouched.
Phase 2 — Carve deliverables (the big one): per pillar, cluster the open-issue pile into named, completable, this-quarter projects with target dates; rest → backlog holding pen. Driven by a per-pillar agent proposing candidate deliverables from open issues → leads prioritize.
Phase 3 — Sequence the 3-month plan: lay deliverables across ~6 two-week cycles; assign owner + reviewer; wire dependencies. Output = Linear roadmap view + a summary section here.
Phase 4 — Encode: apply work-type labels + create per-pillar maintenance lanes + set capacity convention; build the openclaw detector as the first automation deliverable; write the recurring “audit Linear state” maintenance skill.
Resolved (2026-07-13) — Phase 1 unblocked
- Excadrill / Eevee — in both pillars (Platform runtime + Research logic).
- Side-Projects — Kyogre, YouSim, Dedenne, + Mimikyu, + Honcho Demo UI.
- Capacity — DRIs + ~20% reservation for integration maintenance; rotating on-call for support + OSS contributions (see Support section).
- SDK / CLI — under Product: CLI lead = Abigail; SDKs = Eugene / Aakash / Vineeth cadence. Integration DRIs: openclaw & Hermes → Eri; Claude Code → TBD.
Remaining minor TBD: Claude Code integration DRI.