From 67d735ddec1e4b624d6ee1463471143647f881d2 Mon Sep 17 00:00:00 2001 From: tegwick Date: Thu, 16 Jul 2026 02:34:24 +0200 Subject: [PATCH] Seeded initial INTENT --- .custodian-brief.md | 27 + .gitignore | 6 + AGENTS.md | 180 ++ INTENT.md | 105 + SCOPE.md | 37 + history/260715-InitialExploration.md | 2238 +++++++++++++++++ workplans/BINKY-WP-0001-statehub-bootstrap.md | 55 + 7 files changed, 2648 insertions(+) create mode 100644 .custodian-brief.md create mode 100644 AGENTS.md create mode 100644 INTENT.md create mode 100644 SCOPE.md create mode 100644 history/260715-InitialExploration.md create mode 100644 workplans/BINKY-WP-0001-statehub-bootstrap.md diff --git a/.custodian-brief.md b/.custodian-brief.md new file mode 100644 index 0000000..06c4d7b --- /dev/null +++ b/.custodian-brief.md @@ -0,0 +1,27 @@ + +# Custodian Brief - binky-control + +**Project:** binky-control +**Domain:** infotech +**State Hub:** http://127.0.0.1:8000 +**Topic ID:** `cee7bedf-2b48-46ef-8601-006474f2ad7a` + +## Open Workplans + +### Bootstrap State Hub integration + +Workplan file: `workplans/BINKY-WP-0001-statehub-bootstrap.md` + +Open tasks: +- T01 - Review generated integration files +- T02 - Verify local developer workflow +- T03 - Seed first real workplan + +## Session Start + +1. Read `INTENT.md`, `SCOPE.md`, and `AGENTS.md`. +2. Check inbox: `GET /messages/?to_agent=binky-control&unread_only=true`. +3. Scan `workplans/`. +4. Update task statuses in workplan files as work progresses. + +Last generated: 2026-07-16 diff --git a/.gitignore b/.gitignore index ab3e8ce..73caa0b 100644 --- a/.gitignore +++ b/.gitignore @@ -162,3 +162,9 @@ cython_debug/ # option (not recommended) you can uncomment the following to ignore the entire idea folder. #.idea/ + +# state-hub: track .claude/rules +# Claude Code local state (track shared rules; ignore machine-specific files) +.claude/* +!.claude/rules/ +!.claude/rules/*.md diff --git a/AGENTS.md b/AGENTS.md new file mode 100644 index 0000000..8b7f81f --- /dev/null +++ b/AGENTS.md @@ -0,0 +1,180 @@ +# binky-control — Agent Instructions + +## Repo Identity + +**Purpose:** binky-control is the company control plane ("company brain") for Binky Hedgehog GmbH's transformation into Operational Knowledge GmbH, holding the canon (intent, policies, plans), work queues, and registries that give agents and the solo founder shared situational awareness with executable next steps. + +**Domain:** infotech +**Repo slug:** binky-control +**Topic ID:** `cee7bedf-2b48-46ef-8601-006474f2ad7a` +**Workplan prefix:** `BINKY-WP-` + +--- + +## State Hub Integration + +The Custodian State Hub tracks work across all domains. Interact via HTTP REST — +there is no MCP server for Codex agents. + +| Context | URL | +|---------|-----| +| Local workstation | `http://127.0.0.1:8000` | +| Remote via tunnel | `http://127.0.0.1:18000` | +| Optional local edge relay | http://127.0.0.1:18080 | + +When an operator has enabled the edge relay, set API_BASE to the relay URL. +Queueable writes return an explicit queued receipt if the central hub is +unreachable. Treat that as pending local evidence, then ask the operator to run +statehub outbox status/replay after connectivity returns. + +### Orient at session start + +```bash +# Offline brief — works without hub connection +cat .custodian-brief.md + +# Active workplans for this domain +curl -s "http://127.0.0.1:8000/workplans/?topic_id=cee7bedf-2b48-46ef-8601-006474f2ad7a&status=active" \ + | python3 -m json.tool + +# Check inbox +curl -s "http://127.0.0.1:8000/messages/?to_agent=binky-control&unread_only=true" \ + | python3 -m json.tool +``` + +Mark a message read: +```bash +curl -s -X PATCH "http://127.0.0.1:8000/messages//read" \ + -H "Content-Type: application/json" -d '{}' +``` + +### Log progress (required at session close) + +```bash +curl -s -X POST http://127.0.0.1:8000/progress/ \ + -H "Content-Type: application/json" \ + -d '{ + "summary": "what was done", + "event_type": "note", + "author": "codex", + "workplan_id": "", + "task_id": "" + }' +``` + +Omit `workplan_id` / `task_id` when not applicable. + +### Update task status + +```bash +curl -s -X PATCH "http://127.0.0.1:8000/tasks/" \ + -H "Content-Type: application/json" \ + -d '{"status": "progress"}' +# values: wait | todo | progress | done | cancel +``` + +### Flag a task for human review + +```bash +curl -s -X PATCH "http://127.0.0.1:8000/tasks/" \ + -H "Content-Type: application/json" \ + -d '{"needs_human": true, "intervention_note": "reason"}' +``` + +--- + +## Session Protocol + +**Start:** +1. `cat .custodian-brief.md` — domain goal and open workplans (offline-safe) +2. Check inbox: `GET /messages/?to_agent=binky-control&unread_only=true`; mark read +3. Scan workplans: `ls workplans/` — note `status: ready`, `active`, or `blocked` files and open tasks +4. Check human-needed tasks: `GET /tasks/?needs_human=true` + +**During work:** +- Update task statuses in workplan files as tasks progress +- Record significant decisions via `POST /decisions/` + +**Close:** +1. Update workplan file task statuses to reflect progress +2. Log: `POST /progress/` with a summary of what changed +3. After workplan file changes, run: + ```bash + statehub fix-consistency + ``` + Coding agents should run this directly; ask the operator only if the CLI or + State Hub API is unavailable. This syncs task status from files into the hub DB. + +--- + +{CREDENTIAL_ROUTING} + + + + +--- + +## Workplan Convention (ADR-001) + +Work items originate as files in this repo — not in the hub. The hub is a +read/cache/index layer that rebuilds from files. + +**File location:** `workplans/BINKY-WP-NNNN-.md` + +**Archived location:** finished workplans may move to +`workplans/archived/YYMMDD-BINKY-WP-NNNN-.md`. The `YYMMDD` prefix is +the completion/archive date; the frontmatter `id` does not change. + +**Ad Hoc Tasks:** small opportunistic fixes discovered during a session use +`workplans/ADHOC-YYYY-MM-DD.md` with task ids `ADHOC-YYYY-MM-DD-T01`, etc. Use +this only for low-risk work completed directly; create a normal workplan for +anything needing analysis, design, approval, dependencies, or multiple phases. + +**Frontmatter:** + +```yaml +--- +id: BINKY-WP-NNNN +type: workplan +title: "..." +domain: infotech +repo: binky-control +status: proposed | ready | active | blocked | backlog | finished | archived +owner: codex +topic_slug: ... +created: "YYYY-MM-DD" +updated: "YYYY-MM-DD" +state_hub_workstream_id: "" # fix-consistency — do not edit (legacy field name; workplan UUID) +--- +``` + +Use `proposed` for a new draft, `ready` after review against current repo +state, and `finished` after implementation. `stalled` and `needs_review` are +derived health labels, not frontmatter statuses. + +**Terminology:** workplan is the fleet term; `workstream` appears only in legacy +API/MCP/frontmatter bridges until `STATE-WP-0069` retires them — see +`the-custodian/canon/standards/workplan-terminology-fleet_v0.1.md`. + +**Task block format** (one per `##` section): + +``` +## Task Title + +` ` `task +id: BINKY-WP-NNNN-T01 +status: wait | todo | progress | done | cancel +priority: high | medium | low +state_hub_task_id: "" # written by fix-consistency — do not edit +` ` ` + +Task description text. +``` + +Status progression: `todo` → `progress` → `done`; use `wait` for waiting/blocked work and `cancel` for stopped work. + +To create a new workplan: +1. Write the file following the format above +2. Run `statehub fix-consistency` locally; ask the operator only if the CLI or + State Hub API is unavailable. diff --git a/INTENT.md b/INTENT.md new file mode 100644 index 0000000..8bd9cc3 --- /dev/null +++ b/INTENT.md @@ -0,0 +1,105 @@ +# INTENT + +> Status: **draft v0.1** — 2026-07-16. Owner: Bernd Worsch. To be revised as the company canon grows. + +## Why this company exists + +Binky Hedgehog GmbH (founded 2019, until now a dormant legal shell) becomes the +commercial operating company for an ecosystem of **operational knowledge +infrastructure**. Its long-term identity is **Operational Knowledge GmbH — "OK"**. + +The thesis: + +> Companies increasingly fail not because they lack tools, but because their +> operational knowledge is fragmented, implicit, ungoverned, and not executable. +> This company provides products and services that turn operational knowledge +> into structured, governed, agent-ready company capabilities. + +## What the company does + +The company is the **economic crystallization point** of the ecosystem — it is +not the ecosystem itself. + +- **Package** capabilities from the ecosystem into offers. +- **Sell and deliver** those offers to earn revenue. +- **Operate itself** on the same capabilities (dogfooding), turning every + internal operational pain into product evidence. +- **Feed learning back** into the ecosystem so capabilities mature. + +The ecosystem pillars and their roles: + +| Pillar | Role | +| --- | --- | +| **Coulomb** | Discover, cluster, mature, and package reusable capabilities | +| **Net Kingdom** | Identity, access, security, governance — make capability governable | +| **Railiance** | Reliable coordination and delivery — turn intentions into fulfilled commitments | + +## The core loop: the OK Flywheel + +1. An internal operational problem appears. +2. The company solves it with an ecosystem capability. +3. The solution is documented and instrumented. +4. The capability becomes reusable. +5. The reusable capability becomes a product or service. +6. Customer usage creates feedback. +7. Feedback improves the ecosystem. +8. The improved ecosystem improves company operations. + +## How the company is operated + +The company runs as a **human-on-the-loop, unattended-progress stack**: a solo +founder with ~1–3 hours per day outside business hours and roughly two +office-hour days per month. + +Operating rules that follow from this: + +- **"Ask Bernd" is never the default.** Agents continue with the safest useful + next step; uncertainty triggers research, comparison, or preparation — never + idle waiting. +- Work is classified into **autonomy lanes** (Green/Blue/Yellow/Orange/Red, + defined in `AutonomyPolicy.md`). Green and Blue work proceeds unattended; + Yellow becomes prepared decision packages; Orange batches to office-hour + days; Red stays human-only. +- Founder attention is the scarcest resource and is **budgeted explicitly**: + concise briefs, evidence-backed decision cards, approve/reject options. +- Valid system states are *proceeding*, *prepared for review*, or *deferred by + policy* — never *waiting because unsure*. + +## What must remain human + +Signing, strategic commitments, bank and payment execution, contracts, +sensitive legal/HR/security decisions, external commitments of the company, +risk acceptance, and final authority on direction. Agents prepare; the founder +decides. + +## What counts as success + +The success ladder (detail in `SuccessMilestones.md`): + +```text +S1 company administratively clean +S3 first internal dogfood loop works +S5 first paid revenue +S6 repeatable productized service +S9 rename to Operational Knowledge GmbH makes sense +S12 acquiring ok.com becomes a rational decision +``` + +The rename to Operational Knowledge GmbH is a **milestone, not a starting +point** — it happens when the name clarifies the business more than it creates +friction (first repeatable offer, paying customer or serious pilot, coherent +messaging, dogfood evidence). + +## Near-term aim + +Make Binky Hedgehog GmbH practically operable and strategically aimed at +becoming Operational Knowledge GmbH: reactivate the legal/administrative +shell, map the ecosystem, form first offers (services before software), and +run the company on its own primitive control plane — this repo. + +## This repo + +`binky-control` is the company brain: the canon (intent, policies, plans), +the queues (decisions, office-hour, autopilot work), and the registries that +let agents and the founder share situational awareness with executable next +steps. Sister repo: `unattended-progress-company`. diff --git a/SCOPE.md b/SCOPE.md new file mode 100644 index 0000000..18796bc --- /dev/null +++ b/SCOPE.md @@ -0,0 +1,37 @@ +# SCOPE + +> This file was generated by `statehub register`. Refine it as the repository +> boundaries become clearer. + +## One-liner + +binky-control is the company control plane ("company brain") for Binky Hedgehog GmbH's transformation into Operational Knowledge GmbH, holding the canon (intent, policies, plans), work queues, and registries that give agents and the solo founder shared situational awareness with executable next steps. + +## Core Idea + +binky-control exists to provide the capability described in INTENT.md. + +## In Scope + +- Company canon: intent, policies (autonomy lanes), success milestones +- Queues for decisions, office-hour batches, and autopilot work +- Registries for founder/agent shared situational awareness +- Operating the human-on-the-loop, unattended-progress stack +- Dogfooding ecosystem capabilities on company operations + +## Out of Scope + +- Building the ecosystem pillars themselves (Coulomb, Net Kingdom, Railiance) +- Product/service source code and delivery artifacts +- Human-only actions: signing, contracts, payments, legal/HR/security decisions +- Sister-repo concerns tracked in unattended-progress-company + +## Current State + +- Early draft stage: single initial commit, INTENT.md at draft v0.1 (2026-07-16), referenced policy/milestone docs not yet present in the repo. + +## Getting Oriented + +- Start with: INTENT.md +- Agent instructions: AGENTS.md +- Workplans: workplans/ diff --git a/history/260715-InitialExploration.md b/history/260715-InitialExploration.md new file mode 100644 index 0000000..7dfd32a --- /dev/null +++ b/history/260715-InitialExploration.md @@ -0,0 +1,2238 @@ +# Prompt 1: Running a Company + +Given I want to establish an agentic stack to run a company on, how would I approach this systematically? + +# Answer: + +You should approach it as building a **Company Operating System**, not as sprinkling agents over existing tools. + +The central question is not: “Which agents do I need?” +It is: **Which company control loops should become inspectable, semi-automated, and eventually agent-operated?** + +## 1. Start with the company as a system of control loops + +Model the company as nested loops: + +**Sense → Interpret → Decide → Act → Record → Learn** + +Every business function can be expressed this way: + +| Area | Sense | Decide | Act | Record | +| ---------------- | ----------------------- | ------------------------ | ------------------- | ----------------- | +| Sales | leads, signals, replies | qualify, prioritize | outreach, follow-up | CRM, evidence | +| Finance | invoices, cash, spend | approve, forecast | pay, collect | ledger, reports | +| Product | feedback, usage, market | roadmap, scope | tickets, releases | PRDs, changelog | +| Operations | incidents, SLAs | triage, assign | runbooks, recovery | logs, postmortems | +| Legal/compliance | contracts, risks | accept, reject, escalate | filings, approvals | audit trail | + +Your first artifact should be a **Company Control Loop Catalog**. Each loop gets: + +* intent +* inputs +* outputs +* responsible human role +* permitted agent actions +* required evidence +* escalation rules +* KPIs +* risk class + +This gives you an architecture before you choose tools. + +## 2. Define the “agentic stack” in layers + +I would structure the stack like this: + +```text +Company Intent Layer + Mission, strategy, policies, operating principles + +Control Loop Layer + Sales loops, finance loops, delivery loops, product loops, ops loops + +Capability Registry Layer + What the company can do; maturity, owners, APIs, docs, SLAs + +Agent Role Layer + Analyst agents, coordinator agents, operator agents, reviewer agents + +Tool & Integration Layer + Email, calendar, CRM, accounting, Git, documents, ticketing, banking, BI + +Memory & Knowledge Layer + Company canon, policies, decisions, customer context, project memory + +Evidence & Audit Layer + Citations, logs, approvals, decisions, source snapshots, run history + +Governance & Safety Layer + Identity, permissions, approval gates, risk classes, monitoring + +Execution Runtime Layer + Workflows, queues, durable tasks, model routing, observability +``` + +The important distinction: **agents should not own the company. They should operate bounded capabilities under governance.** + +## 3. Use agent roles, not generic agents + +Avoid “the sales agent”, “the CEO agent”, “the finance agent” too early. Those are too vague. + +Use precise operating roles: + +* **Scout**: gathers information. +* **Analyst**: compares, summarizes, scores. +* **Planner**: proposes next actions. +* **Coordinator**: routes work between people, agents, and systems. +* **Operator**: executes approved actions. +* **Reviewer**: checks evidence, risk, policy, and quality. +* **Archivist**: records decisions, artifacts, and traceability. +* **Controller**: watches KPIs and triggers escalation. + +For example, in finance: + +```text +Invoice Scout → extracts invoice data +Finance Analyst → compares invoice to contract / PO / budget +Approval Coordinator → routes approval to responsible person +Payment Operator → prepares payment, but does not execute without approval +Evidence Archivist → stores invoice, approval, payment reference +Controller → watches cash impact and budget variance +``` + +That is much safer and more scalable than a vague “finance agent”. + +## 4. Build around registries + +A company-running agentic stack needs registries more than chatbots. + +I would define these core registries: + +| Registry | Purpose | +| --------------------------- | ------------------------------------------------------------- | +| **Capability Registry** | What the organization can do, who owns it, how mature it is | +| **Tool Registry** | What tools agents may use, with scopes and permissions | +| **Agent Registry** | Which agents exist, their role, model, permissions, owner | +| **Policy Registry** | Rules for approval, privacy, spending, contracts, security | +| **Evidence Registry** | Where claims, decisions, documents, and actions are recorded | +| **Process / Loop Registry** | Recurring company loops and their current automation maturity | +| **Risk Registry** | Known failure modes, mitigations, human escalation paths | +| **Context Registry** | Canonical company knowledge, terminology, projects, customers | + +This maps very naturally to several things you already think about: `reuse-surface` as capability registry, `coordination-engine` as interaction/delivery runtime, `feature-control` as gated availability, `identity-canon` / `user-engine` as principal modeling, `citation-evidence` as provenance, and `ConfigAtlas` as configuration surface. + +## 5. Separate workflow durability from agent reasoning + +For serious company operations, do not let the LLM be the workflow engine. + +Use agents for reasoning and interpretation. Use durable workflow infrastructure for state, retries, timeouts, compensation, and auditability. Temporal describes durable execution as crash-proof execution that can resume long-running workflows after infrastructure failures; that class of capability matters when agents are involved in payments, customer communication, onboarding, compliance, or incident response. ([Temporal][1]) + +A healthy pattern is: + +```text +Workflow Engine owns state. +Agent proposes or performs bounded steps. +Policy Engine decides whether action is allowed. +Human approves when needed. +Evidence Layer records everything. +``` + +## 6. Standardize tool access + +Use a tool protocol mindset. MCP is currently a major emerging standard for connecting AI applications to tools, data sources, and workflows through a common interface. ([Model Context Protocol][2]) + +But do not expose tools directly to agents without controls. Every tool should have: + +* identity of calling agent +* allowed operations +* allowed data scope +* rate limits +* approval requirements +* audit logs +* rollback or compensation behavior +* test sandbox +* production boundary + +So instead of “agent can use Gmail”, define: + +```yaml +tool: gmail.send_email +allowed_for: + - approval_coordinator + - customer_success_operator +requires_approval: + - external_recipient + - contract_related + - financial_commitment +evidence_required: + - source_thread + - generated_draft + - approving_user + - timestamp +``` + +## 7. Treat governance as product architecture, not bureaucracy + +Because you are in Germany / the EU, the compliance frame matters from the beginning. The EU AI Act entered into force on 1 August 2024 and is broadly applicable from 2 August 2026 with phased exceptions; the Commission’s own AI Act timeline also lists 2 August 2026 as the point where the majority of rules and enforcement for applicable rules begin. ([Digitale Strategie der EU][3]) + +For management-system thinking, ISO/IEC 42001 is directly relevant because it defines an AI management system for organizations developing, providing, or using AI systems, with emphasis on risk management, accountability, and continual improvement. ([ISO][4]) NIST’s AI Risk Management Framework is also useful as a practical structure for identifying and managing AI risks. ([NIST][5]) + +In your stack, governance should become executable: + +```text +Policy as code +Approval as workflow +Evidence as default +Risk class as metadata +Audit trail as product feature +``` + +## 8. Build the first version as an “agentic management cockpit” + +The first product should not autonomously run the company. It should make the company legible. + +A good MVP would be: + +**Agentic Company Cockpit v0** + +Capabilities: + +1. ingest company documents, emails, tickets, calendar, repos, accounting exports +2. maintain a company context graph +3. list active control loops +4. show open decisions +5. show risks and blocked work +6. draft actions, but not execute sensitive actions +7. maintain evidence-backed weekly operating review +8. route follow-ups to people +9. generate capability maturity snapshots +10. track what agents did, suggested, and learned + +The killer feature is not autonomy. +The killer feature is **shared situational awareness with executable next steps**. + +## 9. Use maturity levels for automation + +Each process should move through levels: + +| Level | Description | +| ------------------------------ | ----------------------------------------------------- | +| L0 Manual | Human does everything | +| L1 Assisted | Agent summarizes, drafts, explains | +| L2 Structured | Agent works inside templates and checklists | +| L3 Recommended | Agent proposes decisions with evidence | +| L4 Supervised execution | Agent executes low-risk actions with logs | +| L5 Conditional autonomy | Agent acts within thresholds and escalates exceptions | +| L6 Closed-loop optimization | Agent monitors outcomes and improves policies | +| L7 Auditable company subsystem | Stable, governed, measurable, replaceable | + +This prevents the classic mistake: automating before understanding. + +## 10. Pick a narrow first operating domain + +I would start with one of these: + +### Option A: Founder / management operating loop + +Best for your own company-building. + +```text +Inputs: notes, repos, chats, calendar, invoices, product docs +Outputs: weekly priorities, decisions, risks, next actions +Agents: scout, analyst, planner, archivist, controller +``` + +This creates the “company brain” first. + +### Option B: Sales / customer-development loop + +Best if revenue is urgent. + +```text +Inputs: leads, website visits, emails, product pages, proposals +Outputs: qualified opportunities, outreach drafts, follow-up tasks +Agents: market scout, account analyst, outreach drafter, CRM archivist +``` + +This creates commercial traction. + +### Option C: Finance / admin loop + +Best if operational sovereignty is urgent. + +```text +Inputs: invoices, bank exports, contracts, Stripe/Bubble data +Outputs: cash view, approval queue, forecast, payment prep +Agents: invoice scout, finance analyst, approval coordinator, evidence archivist +``` + +This creates company control. + +My instinct for you: start with **A + C**. Build the operating kernel and financial control loop before scaling sales automation. + +## 11. Suggested architecture for your context + +```text +agentic-company-stack/ + company-canon/ + INTENT.md + OperatingPrinciples.md + DecisionPolicy.md + RiskPolicy.md + + registries/ + capabilities/ + agents/ + tools/ + policies/ + control-loops/ + evidence/ + risks/ + + runtime/ + workflow-engine/ + agent-orchestrator/ + model-router/ + tool-gateway/ + approval-service/ + evidence-ledger/ + + adapters/ + gmail/ + calendar/ + drive/ + github/ + stripe/ + bubble/ + accounting/ + crm/ + + cockpit/ + dashboard/ + review-briefs/ + decision-inbox/ + risk-board/ + action-queue/ + + governance/ + ai-management-system/ + audit-pack/ + human-oversight/ + red-team-tests/ +``` + +For orchestration, modern frameworks are converging around durable execution, human-in-the-loop, tool calling, tracing, and guardrails. OpenAI’s Agents SDK positions agents as applications that plan, call tools, collaborate, and keep state; its guardrails are designed for input and output validation. ([OpenAI Entwickler][6]) LangGraph emphasizes durable execution, streaming, persistence, and human-in-the-loop orchestration. ([Docs by LangChain][7]) OpenTelemetry remains the obvious baseline for observability because it standardizes telemetry generation, collection, and export for traces, metrics, and logs. ([OpenTelemetry][8]) + +Security should be designed in from the beginning. OWASP now has a Top 10 specifically for Agentic Applications 2026, focused on autonomous systems that plan, act, and make decisions across workflows. ([OWASP Gen AI Security Project][9]) + +## 12. The first concrete workplan + +I would proceed in six steps. + +### Step 1: Define the operating philosophy + +Create: + +```text +AgenticCompanyOperatingSystem_INTENT.md +``` + +Answer: + +* What should agents help the company become? +* What must remain human? +* What is never delegated? +* What counts as evidence? +* What counts as a reversible vs irreversible action? +* What level of autonomy is acceptable per domain? + +### Step 2: Create the Company Control Loop Catalog + +Start with 10–15 loops: + +* weekly management review +* cash and runway review +* invoice processing +* opportunity tracking +* product discovery +* product delivery +* incident response +* security review +* customer support +* contract review +* hiring / people admin +* content / marketing publishing +* vendor management +* compliance evidence collection + +### Step 3: Build the registries + +Minimum viable registries: + +```text +CapabilityRegistry.md +AgentRegistry.md +ToolRegistry.md +PolicyRegistry.md +EvidenceRegistry.md +ControlLoopRegistry.md +``` + +Do not over-engineer. Markdown first, schema second, service third. + +### Step 4: Implement one evidence-backed cockpit + +The first dashboard should answer: + +```text +What changed? +What matters? +What is blocked? +What needs a decision? +What can be safely automated? +What needs human review? +What evidence supports this? +``` + +### Step 5: Add bounded agents + +Start with non-destructive agents: + +* company context scout +* weekly review summarizer +* finance evidence collector +* decision inbox organizer +* repo capability mapper +* policy checker +* follow-up drafter + +Avoid agents that send, delete, pay, sign, or commit until your approval and evidence system is mature. + +### Step 6: Gradually raise autonomy + +Use a per-loop autonomy register: + +```yaml +loop: invoice_processing +current_level: L2 +target_level: L4 +human_owner: founder +agent_roles: + - invoice_scout + - finance_analyst + - approval_coordinator +allowed_actions: + - extract_invoice_data + - compare_to_contract + - prepare_approval_note +forbidden_actions: + - execute_payment + - change_bank_details +evidence_required: + - invoice_file + - vendor_record + - contract_or_order + - approval_timestamp +escalation: + - amount_over_threshold + - new_vendor + - bank_detail_change +``` + +## My recommended framing + +Call the overall thing something like: + +**Agentic Operating Kernel** +or +**Company Control Plane** +or +**Helix Company OS** + +Definition: + +> An agentic company stack is a governed operating system for organizational control loops, where agents sense, interpret, plan, coordinate, and execute bounded actions through registered tools, under explicit policy, with evidence, observability, and human accountability by default. + +The strongest path is: + +```text +1. Make the company observable. +2. Make work explicit. +3. Make decisions evidence-backed. +4. Make tools governable. +5. Make agents bounded. +6. Make autonomy gradual. +7. Make learning systematic. +``` + +That gives you something much more valuable than “AI agents for business”. It becomes a **cybernetic company infrastructure**: a system that understands its own state, coordinates its own work, and improves its own operating model without losing human sovereignty. + +[1]: https://temporal.io/blog/what-is-durable-execution?utm_source=chatgpt.com "The definitive guide to Durable Execution" +[2]: https://modelcontextprotocol.io/docs/getting-started/intro?utm_source=chatgpt.com "Model Context Protocol" +[3]: https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai?utm_source=chatgpt.com "AI Act | Shaping Europe's digital future - European Union" +[4]: https://www.iso.org/home/insights-news/resources/iso-42001-explained-what-it-is.html?utm_source=chatgpt.com "ISO 42001 explained" +[5]: https://www.nist.gov/itl/ai-risk-management-framework?utm_source=chatgpt.com "AI Risk Management Framework | NIST" +[6]: https://developers.openai.com/api/docs/guides/agents?utm_source=chatgpt.com "Agents SDK | OpenAI API" +[7]: https://docs.langchain.com/oss/python/langgraph/overview?utm_source=chatgpt.com "LangGraph overview - Docs by LangChain" +[8]: https://opentelemetry.io/docs/what-is-opentelemetry/?utm_source=chatgpt.com "What is OpenTelemetry?" +[9]: https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/?utm_source=chatgpt.com "OWASP Top 10 for Agentic Applications for 2026" + + +# Prompt 2: Unblocking Progress + +This is a good plan but I need you to adapt for the following boundary condition: I will for some time be the only human in the loop and must not be a blocker if daily progress even if I am not available at all for some days and will have a limited time budget of about 1 to 3 hours a day that are out of the usual business hour time window but for two days a month. + +# Answer + +The key adaptation is: + +> You do **not** need a human-in-the-loop company. +> You need a **human-on-the-loop company** with explicit autonomy boundaries. + +The system must keep producing progress while you are unavailable, and use your limited time only for decisions that truly require sovereignty, judgment, legal authority, money, or relationship sensitivity. + +## 1. New design principle: never make “ask Bernd” the default + +Most agentic systems fail for solo founders because every uncertain case becomes: + +```text +Blocked: waiting for human input +``` + +Your system needs the opposite default: + +```text +Continue with the safest useful next step. +Escalate only when policy says the action is irreversible, risky, expensive, or identity-bearing. +``` + +So the operating rule becomes: + +> Agents may not need permission to think, analyze, draft, compare, prepare, test, document, simulate, organize, or propose. +> They need permission only to commit the company externally, spend meaningful money, change production systems, sign, delete, publish, or make irreversible decisions. + +That distinction is the core architecture. + +--- + +# Adapted model: the Solo-Agentic Company Stack + +Instead of this: + +```text +Agent → asks human → waits → acts +``` + +Use this: + +```text +Agent → classifies task → acts within autonomy lane → records evidence → prepares decision if needed +``` + +The human becomes a **periodic governor**, not a synchronous gate. + +## 2. Introduce autonomy lanes + +Every activity should be assigned to one of five lanes. + +| Lane | Name | Agent may do | Human needed? | +| ------ | -------------------- | ----------------------------------------------------------------------------------- | ------------------------ | +| Green | Safe autonomous | Research, summarize, classify, draft, organize, test, prepare | No | +| Blue | Reversible execution | Create internal docs, update backlog, run local scripts, prepare reports | No, but logged | +| Yellow | Deferred approval | Prepare external emails, invoices, offers, releases, payments | Yes, later | +| Orange | Time-window approval | Customer/legal/accounting/banking actions needing business-hour interaction | Yes, on office-hour days | +| Red | Human-only | Signing, strategic commitments, bank changes, sensitive legal/HR/security decisions | Always | + +This lets daily progress continue even when you are absent. + +The stack should optimize for: + +```text +Maximize Green + Blue work. +Queue Yellow decisions. +Batch Orange work into two office-hour days per month. +Protect Red work from automation. +``` + +--- + +## 3. Replace “approval needed” with “approval package prepared” + +When an agent reaches a boundary, it should not merely stop. It should prepare a complete decision package. + +A good approval package contains: + +```yaml +decision: "Approve sending follow-up proposal to customer X" +recommended_action: "Send prepared email and attach proposal v3" +reason: "Customer asked for pricing clarification; delay may reduce momentum" +evidence: + - source email + - proposal draft + - pricing rationale + - risk assessment +risk_level: yellow +reversibility: medium +deadline: "2026-07-19" +fallback_if_no_approval: "Do not send; prepare alternative draft and add to next review" +one_click_options: + - approve + - reject + - revise + - defer +``` + +This is crucial because your 1–3 hours per day should not be spent reconstructing context. + +Your human time should be mostly: + +```text +Approve / reject / redirect / set policy +``` + +not: + +```text +Figure out what happened. +``` + +--- + +# 4. Define three operating modes + +Your company stack should explicitly support three modes. + +## Mode A: Evening Operator Mode + +This is your normal 1–3 hour daily window. + +Purpose: + +```text +Clear decision queue. +Review evidence. +Make priority choices. +Give direction. +Avoid getting dragged into execution. +``` + +Your daily dashboard should show only: + +```text +1. Critical risks +2. Decisions needed +3. Progress since last review +4. Blocked items where only you can unblock +5. Suggested next best actions +``` + +A sane daily structure: + +| Time | Activity | +| --------- | ------------------------------- | +| 10 min | Situation brief | +| 20–40 min | Decision queue | +| 30–90 min | One deep founder task | +| 10 min | Set next constraints / policies | + +The agents should use your decisions as new policy, not just one-off instructions. + +--- + +## Mode B: Unattended Autopilot Mode + +This is for days when you are unavailable. + +Agents should keep working on: + +```text +research +documentation +classification +backlog refinement +competitor scans +product specs +test generation +data cleanup +drafting +internal planning +evidence collection +repo analysis +capability mapping +financial preparation +customer context preparation +``` + +They should not wait for you unless the task hits a Yellow, Orange, or Red boundary. + +Autopilot mode needs a queue of evergreen useful work: + +```text +Always Useful Work Queue + - improve project documentation + - refine INTENT / PRD / UseCaseCatalog files + - analyze repos for missing metadata + - collect market evidence + - prepare sales/account lists + - generate test cases + - improve onboarding docs + - reconcile open tasks + - update capability registry + - summarize unresolved decisions +``` + +This queue prevents the system from becoming idle. + +--- + +## Mode C: Office-Hour Command Days + +You have only about two normal-business-hour days per month. Treat them as scarce strategic infrastructure. + +Those days should be preloaded by agents. + +They should prepare: + +```text +banking actions +accountant questions +legal reviews +customer calls +vendor calls +authority / administration tasks +contract decisions +payment approvals +signature packages +phone calls +appointments +``` + +The system should create an **Office-Hour Runbook** before each of those days: + +```markdown +# Office-Hour Command Day + +## Must do today +1. Call accountant about VAT treatment for X +2. Approve or reject Stripe/Bubble subscription handling +3. Resolve customer proposal deadline +4. Confirm legal wording for contract template + +## Prepared material +- accountant briefing +- cash overview +- draft emails +- unresolved questions +- supporting documents + +## Do not spend time on +- internal documentation +- repo cleanup +- speculative product naming +``` + +This protects those days from being consumed by low-leverage work. + +--- + +# 5. Change the agent roles + +The earlier role model needs to be adapted. You need fewer “operator” agents and more **preparation, continuity, and control agents**. + +## Core agents for a solo-agentic company + +| Agent | Purpose | +| ---------------------------------- | --------------------------------------------------------------- | +| **Chief of Staff Agent** | Maintains priorities, decision queue, daily brief | +| **Autopilot Coordinator** | Keeps safe work moving when you are absent | +| **Evidence Archivist** | Records sources, decisions, assumptions, outputs | +| **Policy Controller** | Checks whether an action is Green, Blue, Yellow, Orange, or Red | +| **Finance Steward** | Tracks invoices, subscriptions, runway, payments-to-approve | +| **Opportunity Scout** | Finds potential customers, partners, monetization paths | +| **Product Steward** | Maintains INTENT, PRD, use cases, roadmap, backlog | +| **Repo Cartographer** | Maps repositories, capabilities, maturity, missing metadata | +| **External Communication Drafter** | Prepares emails/proposals but does not send sensitive ones | +| **Review Packager** | Turns messy work into concise approval packages | + +The most important one is the **Chief of Staff Agent**. + +It should continuously answer: + +```text +What should Bernd look at next? +What can proceed without him? +What is waiting unnecessarily? +What decision would unlock the most progress? +What should be deferred to office-hour days? +``` + +--- + +# 6. Create a “founder attention budget” + +Your scarcest resource is not compute. It is not agents. It is not ideas. + +It is **high-quality founder attention**. + +So the system should budget your attention explicitly. + +Example: + +```yaml +daily_attention_budget: + available_minutes: 90 + reserve_minutes: 15 + max_decisions_per_day: 7 + max_deep_topics_per_day: 1 + preferred_interaction_style: + - concise briefs + - approve/reject options + - evidence links + - no open-ended status dumps +``` + +Decision queue items should have an estimated attention cost: + +```yaml +decision: "Choose first monetization path for Coulomb membership" +attention_cost: 25_minutes +impact: high +urgency: medium +risk: medium +preparedness: 80_percent +recommendation_available: true +``` + +This prevents the system from presenting you with twenty “urgent” things. + +--- + +# 7. Use default policies to avoid needless blocking + +You need pre-decided defaults. + +For example: + +## Research default + +```text +If uncertain, collect evidence and produce a comparison. +Do not ask for clarification unless the ambiguity changes risk or external commitment. +``` + +## Documentation default + +```text +Agents may create and improve internal markdown documents freely. +They must preserve provenance and mark assumptions. +``` + +## Email default + +```text +Agents may draft external emails. +Agents may send only low-risk routine follow-ups if pre-approved by category. +Anything involving pricing, commitments, complaints, contracts, or legal matters enters approval queue. +``` + +## Spending default + +```text +Agents may recommend spending. +Agents may not spend money unless inside an approved recurring budget or explicit threshold. +``` + +## Product default + +```text +Agents may refine specs, use cases, architecture, naming, backlog, and implementation plans. +They may not declare strategic direction final without founder approval. +``` + +## Code default + +```text +Agents may create branches, tests, prototypes, documentation, and local commits. +They may not deploy production changes without policy-approved checks. +``` + +This is how you remove yourself as a blocker without giving up control. + +--- + +# 8. Build around queues, not chats + +A chat interface alone will not run a company. + +You need durable queues: + +```text +Decision Queue +Approval Queue +Office-Hour Queue +Autopilot Work Queue +Risk Queue +Follow-Up Queue +External Communication Queue +Finance Queue +Product Queue +``` + +Each queue item should have: + +```yaml +id: DEC-2026-001 +title: "Approve pricing page direction" +owner: "Bernd" +lane: yellow +status: prepared +created_at: "2026-07-16" +needed_by: "2026-07-20" +attention_cost: "15 min" +agent_recommendation: "Approve option B" +evidence: + - market comparison + - customer profile + - pricing rationale +options: + - approve + - reject + - request revision + - defer +fallback_if_no_response: "Keep drafting internal pricing rationale; do not publish" +``` + +This gives you asynchronous command ability. + +--- + +# 9. Make “absence” an explicit first-class state + +The stack should know whether you are available. + +Example: + +```yaml +founder_availability: + state: unavailable + until: unknown + allowed_escalation: + - critical security incident + - payment failure + - legal deadline + default_behavior: + - continue green work + - continue blue work + - prepare yellow packages + - defer orange work + - never execute red work +``` + +When you return, you should receive: + +```markdown +# Return Brief + +## What changed +## What progressed +## What is waiting for you +## What became stale +## What risks increased +## Recommended decisions for today +``` + +This avoids the classic problem of “I was gone three days and now I need six hours to understand the state.” + +--- + +# 10. Reframe the company stack as an asynchronous factory + +For your situation, the company should operate like this: + +```text +Input streams come in. +Agents normalize them. +Work is decomposed. +Safe work proceeds. +Risky work becomes decision packages. +Founder reviews in batches. +Approved work flows back into execution. +Everything is recorded. +``` + +The goal is not real-time interaction. + +The goal is **continuous preparedness**. + +Even when you are absent, the system should improve: + +```text +more context prepared +more options analyzed +more drafts ready +more risks surfaced +more specs refined +more leads enriched +more evidence collected +more repos mapped +more decisions packaged +``` + +--- + +# 11. Concrete MVP for your boundary condition + +I would not start with full agentic autonomy. + +I would start with this: + +## MVP: Solo Founder Autopilot Cockpit + +### Core artifacts + +```text +CompanyOperatingPrinciples.md +AutonomyPolicy.md +ControlLoopCatalog.md +DecisionQueue.md +OfficeHourQueue.md +AutopilotWorkQueue.md +RiskRegister.md +AgentRegistry.md +ToolRegistry.md +EvidenceLedger.md +DailyBrief.md +ReturnBrief.md +``` + +### First capabilities + +1. Maintain all active projects and repos. +2. Generate daily or return briefs. +3. Keep an explicit decision queue. +4. Classify work into Green / Blue / Yellow / Orange / Red. +5. Prepare approval packages. +6. Maintain office-hour runbooks. +7. Continue safe unattended work. +8. Record assumptions and evidence. +9. Track stale decisions. +10. Suggest next best founder action. + +### First automation domains + +I would choose these three first: + +```text +1. Project / repo operating loop +2. Finance / admin preparation loop +3. Customer / monetization opportunity loop +``` + +Not because they are easiest, but because they map to survival: + +```text +Build capability. +Preserve control. +Find revenue. +``` + +--- + +# 12. Updated architecture + +```text +Solo-Agentic Company Stack + +1. Company Canon + - intent + - principles + - strategy + - autonomy policy + - risk policy + +2. Work Intake + - notes + - emails + - calendar + - repos + - documents + - finance exports + - customer signals + +3. Classification Layer + - domain + - urgency + - risk + - reversibility + - autonomy lane + - attention cost + +4. Queue Layer + - autopilot work queue + - decision queue + - approval queue + - office-hour queue + - risk queue + +5. Agent Layer + - chief of staff + - autopilot coordinator + - evidence archivist + - finance steward + - product steward + - opportunity scout + - repo cartographer + +6. Execution Layer + - safe internal actions + - reversible actions + - draft preparation + - tests + - reports + - documentation + +7. Governance Layer + - policy checks + - approval thresholds + - audit log + - evidence ledger + - escalation rules + +8. Founder Interface + - daily brief + - return brief + - decision cards + - one-click approvals + - office-hour runbook +``` + +--- + +# 13. The most important operating rule + +Use this rule everywhere: + +> If the founder is unavailable, the system must either continue safely, prepare the next decision, or explicitly defer with evidence. It must not silently idle. + +That gives you three valid states: + +```text +Proceeding +Prepared for review +Deferred by policy +``` + +Invalid state: + +```text +Waiting because unsure +``` + +Uncertainty should trigger research, comparison, preparation, or risk classification — not paralysis. + +--- + +# 14. Example: how daily progress continues without you + +Suppose the goal is “monetize Coulomb / HelixForge”. + +While you are absent, agents can: + +```text +scan existing project docs +classify monetizable assets +compare possible customer segments +draft landing page variants +prepare pricing options +map repos to product capabilities +create outreach candidate lists +draft emails +prepare demo narratives +identify missing proof points +write use cases +prepare risk assessment +``` + +They should not: + +```text +send pricing offers +promise delivery dates +sign contracts +change production billing +publish bold claims without review +spend money +``` + +So after three unavailable days, you might return to: + +```text +7 prepared customer hypotheses +3 landing page drafts +1 recommended first monetization path +12 repo capability mappings +4 decision cards +1 office-hour accountant question +2 risks requiring attention +``` + +That is progress. + +--- + +# 15. Suggested autonomy thresholds + +Start conservative: + +| Area | Autonomous? | Limit | +| ------------------- | ----------: | ----------------------------------- | +| Internal docs | Yes | Must preserve previous versions | +| Research | Yes | Must cite/store sources | +| Backlog refinement | Yes | May propose, not delete major items | +| Code prototypes | Yes | Branch only, no production deploy | +| Customer emails | Draft only | Send only after approval | +| Social posts | Draft only | Publish after approval | +| Payments | No | Prepare only | +| Contracts | No | Analyze/draft only | +| Hiring | No | Research/draft only | +| Security changes | Mostly no | Prepare/test only | +| Cloud infra changes | Limited | Non-production only | + +Later, you can raise autonomy where the system proves reliable. + +--- + +# 16. The founder interface should be brutalist + +Do not build a beautiful dashboard first. + +Build a brutally useful one: + +```markdown +# Today + +## 1. Decide now +- DEC-014: Approve first customer segment for ConfigAtlas +- DEC-015: Choose whether to publish Coulomb membership offer + +## 2. Important progress while you were away +- 9 repos classified +- adaptive-pricing PRD refined +- 3 monetization paths compared +- finance subscriptions summarized + +## 3. Risks +- Bubble/Stripe cost assumptions still unverified +- No clear offer page for Coulomb memberships +- Too many parallel product names without priority + +## 4. Best use of your next 60 minutes +Approve or revise the recommended first monetization path. +``` + +This is much better than a generic “agent activity feed”. + +--- + +# 17. Final adapted framing + +Your target is: + +> A solo-founder company control plane where agents continuously prepare, organize, analyze, draft, and execute safe reversible work, while the founder governs through scarce, asynchronous, evidence-backed decision windows. + +Or shorter: + +> **An unattended-progress company stack.** + +Its job is not to replace you. + +Its job is to ensure that your limited attention is applied only where it has sovereign leverage: + +```text +direction +judgment +relationships +commitments +risk acceptance +taste +final authority +``` + +Everything else should be prepared, structured, queued, or safely advanced before you arrive. + + +# Prompt 3: Practical Starting Point + +Good, that captures the spirit nicely. Here is where we will be building from: 1) I have (I think) some interesting infrastructure and ideas that I consider as the ecosystem to build on and to build for with coulomb, net kingdom, railiance. The company will be the provider of products from this ecosystem to earn money and it will itself utilize capabilities from the ecosystem and consume its own dogfood. 2) I have a legal company Binky Hedgehog GmbH that I will reorganize and run practically. I founded the company in 2019 but never made a lot of it. This should now change. At some point in the future I want to rename the company to Operational Knowledge GmbH which shortens to OK nicely. I will know that the company is successful when it makes sense to acquire the domain ok.com. There is success and growth to be captured on the way there. + +# Answer + +Yes. This gives the whole structure a much clearer center of gravity. + +You are not just building an agentic company stack. You are building a **self-consuming ecosystem company**: + +> **Binky Hedgehog GmbH becomes the commercial operating company that turns the Coulomb / Net Kingdom / Railiance ecosystem into products, revenue, operational knowledge, and proof.** + +Later, **Operational Knowledge GmbH** is the mature identity. +“OK” becomes the brand-level condensation of the thesis. + +The core idea could be stated like this: + +> The company earns money by providing operational knowledge products from its ecosystem, while using the same ecosystem internally to operate, learn, automate, and improve itself. + +That is a powerful recursive structure. + +--- + +# 1. Separate the ecosystem from the company + +The first important distinction: + +```text +Ecosystem ≠ Company +``` + +The ecosystem is the capability field. + +The company is the commercial operator. + +## Ecosystem + +The ecosystem contains: + +```text +Coulomb +Net Kingdom +Railiance +HelixForge-style software factory +Knowledge standards +Infrastructure concepts +Reusable capabilities +Open and internal projects +``` + +Its purpose: + +```text +Generate, structure, test, and mature capabilities. +``` + +## Company + +Binky Hedgehog GmbH / future Operational Knowledge GmbH exists to: + +```text +Package capabilities into offers. +Sell them. +Deliver them. +Operate with them. +Prove them. +Improve them. +``` + +The company should not try to “be” the whole ecosystem. It should be the **economic crystallization point**. + +--- + +# 2. Define the company thesis + +I would define the company around this thesis: + +```text +Companies increasingly fail not because they lack tools, +but because their operational knowledge is fragmented, +implicit, ungoverned, and not executable. + +Operational Knowledge GmbH provides products and services +that turn operational knowledge into structured, governed, +agent-ready company capabilities. +``` + +This connects very naturally to your existing threads: + +* ConfigAtlas +* coordination-engine +* reuse-surface +* feature-control +* identity-canon +* citation-evidence +* consistency-frame +* capability maturity +* agentic company stack +* Net Kingdom security / sovereignty +* Coulomb monetization +* Railiance, depending on its final positioning + +The meta-category could be: + +> **Operational Knowledge Infrastructure** + +or: + +> **Company Control Plane Products** + +or: + +> **Agentic Operations Infrastructure** + +--- + +# 3. Give each ecosystem pillar a role + +I would assign the ecosystem pillars clear strategic functions. + +## Coulomb + +Coulomb feels like the **idea, reuse, and product formation surface**. + +Role: + +```text +Coulomb discovers, clusters, matures, and packages reusable capabilities. +``` + +Possible commercial angle: + +```text +Capability registry +Reuse marketplace +Product ideation surface +Repo/product intelligence +Adaptive pricing experiments +Membership/community layer +``` + +Coulomb is where possibilities become structured. + +## Net Kingdom + +Net Kingdom feels like the **sovereign secure operating substrate**. + +Role: + +```text +Net Kingdom provides identity, access, security, governance, +and operational sovereignty for agentic and human systems. +``` + +Possible commercial angle: + +```text +IAM/security stack +OpsBridge +Keycape +OpenBao patterns +PECS +controlled agent access +audit/security architecture +``` + +Net Kingdom is where power becomes governable. + +## Railiance + +From the name, I would position Railiance as the **reliable execution and coordination layer**, unless you already have another sharper meaning. + +Role: + +```text +Railiance coordinates reliable workflows, deliveries, +evidence chains, and operational commitments. +``` + +Possible commercial angle: + +```text +coordination-engine +email-connect +evidence-backed communications +delivery/result tracking +workflow reliability +business process coordination +``` + +Railiance is where intentions become fulfilled commitments. + +Together: + +```text +Coulomb → discover and shape capability +Net Kingdom → secure and govern capability +Railiance → coordinate and deliver capability +``` + +That is a good triad. + +--- + +# 4. Make Binky / OK the dogfooding company + +The company should have two simultaneous missions: + +## External mission + +Sell operational knowledge products. + +```text +We help organizations make their operational knowledge visible, +governable, executable, and agent-ready. +``` + +## Internal mission + +Operate itself through the same stack. + +```text +We run the company as a proof system for our own products. +``` + +This means every internal pain becomes product evidence. + +Examples: + +| Internal need | Dogfooded capability | Product potential | +| ------------------------ | -------------------------------------- | ------------------------------- | +| Track company priorities | Chief of Staff Agent / Company Cockpit | Solo-founder operating cockpit | +| Manage repo ecosystem | reuse-surface / repo cartography | Capability registry product | +| Handle finance/admin | Finance Steward | Agentic admin cockpit | +| Prepare offers | Product Steward / pricing engine | Productization toolkit | +| Control access | Net Kingdom | Agentic security stack | +| Track decisions | citation-evidence | Evidence-backed decision ledger | +| Coordinate communication | coordination-engine / email-connect | Communication evidence product | +| Manage configuration | ConfigAtlas | Configuration control plane | +| Govern agents | AutonomyPolicy / AgentRegistry | Agent governance system | + +The company becomes both: + +```text +producer of operational knowledge infrastructure +consumer of operational knowledge infrastructure +evidence generator for operational knowledge infrastructure +``` + +That is the flywheel. + +--- + +# 5. Establish the “OK Flywheel” + +I would make this explicit. + +```text +1. Internal operational problem appears. +2. Company solves it with ecosystem capability. +3. Solution is documented and instrumented. +4. Capability becomes reusable. +5. Reusable capability becomes product/service. +6. Customer usage creates feedback. +7. Feedback improves ecosystem. +8. Improved ecosystem improves company operations. +``` + +This is your core loop. + +Call it: + +```text +The Operational Knowledge Flywheel +``` + +or simply: + +```text +The OK Flywheel +``` + +It captures the recursive dogfooding logic beautifully. + +--- + +# 6. Define Binky Hedgehog GmbH as the transition vessel + +Binky Hedgehog GmbH does not need to be perfect immediately. It can become a transitional operating shell. + +I would treat the phases like this: + +## Phase 0 — Dormant legal shell + +Current state: + +```text +Company exists legally but has not become the active operating vehicle. +``` + +## Phase 1 — Reactivation + +Goal: + +```text +Make the company administratively alive, clean, compliant, and usable. +``` + +Focus: + +```text +banking +tax/accountant +registered details +bookkeeping +contracts +basic website +email/domain setup +internal company canon +decision records +``` + +## Phase 2 — Operating company + +Goal: + +```text +Use the company to sell first products/services. +``` + +Focus: + +```text +first offer +first customer segment +first invoices +first delivery process +first evidence-backed case studies +``` + +## Phase 3 — Ecosystem provider + +Goal: + +```text +Company becomes the provider of products from Coulomb / Net Kingdom / Railiance. +``` + +Focus: + +```text +product portfolio +support model +pricing model +security posture +repeatable delivery +partner/customer relationships +``` + +## Phase 4 — Operational Knowledge GmbH + +Goal: + +```text +Rename/rebrand when the company identity has caught up with the mission. +``` + +This should happen when the new name clarifies the business more than it creates friction. + +## Phase 5 — OK-level ambition + +Goal: + +```text +Operational Knowledge becomes a category-defining company. +``` + +Symbolic marker: + +```text +Acquiring ok.com makes strategic and economic sense. +``` + +That is a great long-term north star because it is bold, concrete, and slightly absurd in the right way. + +--- + +# 7. Your first company architecture + +I would create three top-level domains: + +```text +Binky / OK +├── Company Operations +├── Ecosystem Productization +└── Market Development +``` + +## Company Operations + +Purpose: + +```text +Make the legal company real, controlled, and operational. +``` + +Includes: + +```text +finance +accounting +legal +tax +banking +domains +email +contracts +compliance +internal governance +``` + +## Ecosystem Productization + +Purpose: + +```text +Turn Coulomb / Net Kingdom / Railiance capabilities into sellable offers. +``` + +Includes: + +```text +capability registry +product candidates +packaging +pricing +MVP offers +delivery playbooks +dogfood evidence +``` + +## Market Development + +Purpose: + +```text +Find customers, validate pain, generate revenue. +``` + +Includes: + +```text +customer segments +use cases +landing pages +outreach +proposals +case studies +partnerships +sales pipeline +``` + +This already gives your agents an operating map. + +--- + +# 8. Start with a Company Canon + +Before tooling, create a minimal canon for Binky / OK. + +```text +company-canon/ + INTENT.md + OperatingPrinciples.md + EcosystemMap.md + CompanyReactivationPlan.md + ProductizationStrategy.md + AutonomyPolicy.md + DecisionPolicy.md + OfferCatalog.md + DogfoodPolicy.md + SuccessMilestones.md +``` + +The most important files: + +## `INTENT.md` + +Defines why the company exists. + +## `EcosystemMap.md` + +Maps Coulomb, Net Kingdom, Railiance, and related projects. + +## `DogfoodPolicy.md` + +Defines how internal operations become product evidence. + +## `OfferCatalog.md` + +Lists what the company can sell now, soon, and later. + +## `CompanyReactivationPlan.md` + +Turns the dormant legal shell into an operating company. + +## `AutonomyPolicy.md` + +Defines what agents may do without you. + +--- + +# 9. Define the company as a portfolio of offers + +Do not start with “products” too narrowly. Start with offers. + +A product may take time. An offer can exist earlier. + +I would classify offers into three levels. + +## Level 1: Advisory / service offers + +Fastest to monetize. + +Examples: + +```text +Operational Knowledge Audit +Configuration Surface Assessment +Agentic Operations Readiness Review +Security / Access Control Architecture Review +Capability Registry Workshop +Digital Communication Evidence Assessment +``` + +These are sellable before the software is complete. + +## Level 2: Productized service offers + +Repeatable packages. + +Examples: + +```text +ConfigAtlas Discovery Sprint +Net Kingdom IAM/Security Bootstrap +Coordination Evidence Setup +Solo-Founder Agentic Cockpit Setup +Capability Registry Implementation +Feature-Control Introduction Package +``` + +These combine consulting, templates, tools, and implementation. + +## Level 3: Software products + +Scalable assets. + +Examples: + +```text +ConfigAtlas +reuse-surface +coordination-engine +email-connect +feature-control +OpsBridge +Keycape +Agentic Company Cockpit +``` + +Your company should earn early revenue from Level 1 and 2 while maturing Level 3. + +That is important. Otherwise you wait too long. + +--- + +# 10. Immediate monetization thesis + +Your strongest initial commercial category may be: + +> **Operational Knowledge Readiness for Agentic Companies** + +Why? + +Because many companies will want agents, but their operational knowledge is too messy: + +```text +unclear processes +fragmented configuration +bad access control +weak evidence +implicit decisions +tribal knowledge +tool sprawl +no capability map +no governance +``` + +Your offer: + +```text +Before agents can run company processes, +your operational knowledge must become visible, +structured, governable, and executable. +``` + +This is exactly where your ecosystem fits. + +Possible first flagship offer: + +```text +Operational Knowledge Audit +``` + +Deliverables: + +```text +- operational knowledge map +- capability inventory +- configuration surface map +- access / identity risk notes +- process/control-loop catalog +- automation readiness score +- agentic autonomy lane recommendations +- prioritized implementation roadmap +``` + +That can be delivered as a service now and later supported by ConfigAtlas, reuse-surface, Net Kingdom, and the agentic cockpit. + +--- + +# 11. The company should run on its own primitive version first + +Before selling an Operational Knowledge Audit to others, do it on Binky itself. + +Create: + +```text +Binky Operational Knowledge Audit v0 +``` + +Assess: + +```text +legal status +tax/accounting status +banking +domains +email +contracts +products +repos +IP ownership +active obligations +costs +revenue paths +available assets +missing capabilities +risks +``` + +This gives you: + +1. practical control over the company, +2. first dogfood evidence, +3. a reusable audit template, +4. a productized service prototype. + +--- + +# 12. The company’s agentic stack should serve the transition + +Your solo-founder constraints still apply. Therefore the first agents should support the reactivation and productization journey. + +## Chief of Staff Agent + +Maintains: + +```text +daily brief +return brief +decision queue +office-hour queue +priority stack +``` + +## Company Reactivation Agent + +Tracks: + +```text +tax/accountant tasks +banking tasks +legal form details +domain/email setup +contracts +administrative deadlines +``` + +## Ecosystem Cartographer + +Maps: + +```text +Coulomb +Net Kingdom +Railiance +repos +documents +capabilities +maturity +product candidates +``` + +## Offer Builder + +Turns capabilities into: + +```text +offers +landing page copy +scope +deliverables +pricing hypotheses +case study structure +``` + +## Dogfood Archivist + +Records: + +```text +internal use cases +before/after states +evidence +lessons learned +product implications +``` + +## Finance Steward + +Tracks: + +```text +costs +subscriptions +cash +invoices +pricing assumptions +revenue experiments +``` + +This is enough for the first version. + +--- + +# 13. Updated control loops for Binky / OK + +I would define these initial control loops. + +## Loop 1: Company Reactivation Loop + +```text +Sense: unresolved legal/admin/tax/company setup issues +Interpret: classify blockers, deadlines, external dependencies +Decide: what must be handled by Bernd/accountant/legal/bank +Act: prepare documents, emails, appointments, checklists +Record: decisions, evidence, status +Learn: update reactivation playbook +``` + +## Loop 2: Ecosystem Cartography Loop + +```text +Sense: repos, notes, documents, project ideas +Interpret: classify into Coulomb / Net Kingdom / Railiance / other +Decide: maturity, product relevance, next action +Act: update registries and maps +Record: capability entries +Learn: improve classification standard +``` + +## Loop 3: Dogfood Loop + +```text +Sense: internal operational pain +Interpret: map pain to ecosystem capability +Decide: use/build/adapt capability +Act: solve internally +Record: evidence and reusable pattern +Learn: update productization backlog +``` + +## Loop 4: Offer Formation Loop + +```text +Sense: capability + market pain + proof +Interpret: package into offer +Decide: target customer and promise +Act: draft offer page, outreach, proposal +Record: offer catalog and validation evidence +Learn: adjust pricing/scope +``` + +## Loop 5: Revenue Development Loop + +```text +Sense: leads, conversations, opportunities +Interpret: fit, urgency, ability to pay +Decide: pursue / nurture / ignore +Act: prepare outreach and proposals +Record: CRM/evidence +Learn: improve segment focus +``` + +## Loop 6: Founder Attention Loop + +```text +Sense: available time and decision backlog +Interpret: highest leverage use of next 1–3 hours +Decide: what Bernd should review now +Act: present decision packages +Record: decisions and new policies +Learn: reduce future attention cost +``` + +This last loop is crucial. + +--- + +# 14. Define the transition from Binky to OK + +Do not rename too early. + +Use the rename as a milestone. + +## Rename readiness criteria + +The company should become **Operational Knowledge GmbH** when most of these are true: + +```text +- first repeatable offer exists +- company has clean accounting/admin operations +- website and messaging are coherent +- at least one paying customer or serious pilot exists +- ecosystem map is understandable to outsiders +- dogfood evidence exists +- product direction is narrower than the full idea cloud +- “Operational Knowledge” clearly describes what is being sold +``` + +Until then, Binky Hedgehog GmbH can be the internal legal vessel and experimental shell. + +Potential external wording during transition: + +```text +Binky Hedgehog GmbH develops operational knowledge infrastructure for agentic, secure, and self-improving organizations. +``` + +Later: + +```text +Operational Knowledge GmbH helps organizations make operational knowledge visible, governable, executable, and agent-ready. +``` + +--- + +# 15. Success ladder toward “ok.com” + +I love the ok.com marker because it creates a mythic endpoint. But you need intermediate markers. + +## Success ladder + +```text +S0 — Legal vessel exists +S1 — Company is administratively clean +S2 — Company has active operating system +S3 — First internal dogfood loop works +S4 — First external offer published +S5 — First paid revenue +S6 — Repeatable productized service +S7 — Software-supported delivery +S8 — Multiple customers +S9 — Operational Knowledge rename makes sense +S10 — Category identity emerges +S11 — OK becomes a serious brand +S12 — ok.com becomes a rational acquisition +``` + +This makes the absurd future concrete without letting it distort the present. + +--- + +# 16. What to do first + +I would start with a **Binky / OK Operating Kernel**. + +Not software first. A repo first. + +```text +binky-control/ + README.md + INTENT.md + CompanyReactivationPlan.md + EcosystemMap.md + OperationalKnowledgeThesis.md + DogfoodPolicy.md + OfferCatalog.md + ControlLoopCatalog.md + AutonomyPolicy.md + DecisionQueue.md + OfficeHourQueue.md + RiskRegister.md + SuccessMilestones.md +``` + +This repo becomes the company brain. + +## First sprint objective + +```text +Make Binky Hedgehog GmbH practically operable and strategically aimed at becoming Operational Knowledge GmbH. +``` + +## First sprint deliverables + +```text +1. Company INTENT.md +2. Company reactivation checklist +3. Ecosystem map +4. First offer catalog +5. Autonomy policy for solo-founder operation +6. Decision queue +7. Office-hour runbook +8. Dogfood loop definition +``` + +--- + +# 17. First version of the company intent + +Here is a concise seed: + +```markdown +# INTENT.md + +Binky Hedgehog GmbH exists to become the commercial operating company for an ecosystem of operational knowledge infrastructure. + +The company develops, uses, and provides products that make organizational capabilities visible, governable, executable, secure, and agent-ready. It builds from the Coulomb, Net Kingdom, and Railiance ecosystem and dogfoods these capabilities internally to run itself with increasing clarity, autonomy, and evidence. + +The long-term company identity is Operational Knowledge GmbH: a company dedicated to turning operational knowledge into a practical control plane for modern organizations. + +The company succeeds by converting internal operational needs into reusable capabilities, reusable capabilities into productized offers, and productized offers into revenue, customer proof, and compounding ecosystem maturity. +``` + +--- + +# 18. Strategic north star + +I would summarize the whole thing as: + +> **Binky Hedgehog GmbH is the chrysalis. Operational Knowledge GmbH is the butterfly. Coulomb, Net Kingdom, and Railiance are the organs of the ecosystem. The agentic company stack is the nervous system. Dogfooding is the metabolism. Revenue is the proof of life.** + +That is the story. + +The practical next move is to create the **binky-control** repo as the control plane for the legal company, the ecosystem, the dogfooding process, and the path toward OK. + +# Closing Remark + +I established the binky-control repo and a sister repo called unattended-progress-company. + +Let's do this! + +xxx diff --git a/workplans/BINKY-WP-0001-statehub-bootstrap.md b/workplans/BINKY-WP-0001-statehub-bootstrap.md new file mode 100644 index 0000000..e202ad1 --- /dev/null +++ b/workplans/BINKY-WP-0001-statehub-bootstrap.md @@ -0,0 +1,55 @@ +--- +id: BINKY-WP-0001 +type: workplan +title: "Bootstrap State Hub integration" +domain: infotech +repo: binky-control +status: ready +owner: codex +topic_slug: custodian +created: "2026-07-16" +updated: "2026-07-16" +--- + +# Bootstrap State Hub integration + +binky-control is the company control plane ("company brain") for Binky Hedgehog GmbH's transformation into Operational Knowledge GmbH, holding the canon (intent, policies, plans), work queues, and registries that give agents and the solo founder shared situational awareness with executable next steps. + +## Review Generated Integration Files + +```task +id: BINKY-WP-0001-T01 +status: todo +priority: high +``` + +Review `INTENT.md`, `SCOPE.md`, `AGENTS.md`, and `.custodian-brief.md`. +Replace generated placeholders with repo-specific facts where needed. + +## Verify Local Developer Workflow + +```task +id: BINKY-WP-0001-T02 +status: todo +priority: high +``` + +Identify the repo's install, test, lint, build, and run commands. Add or refine +those commands in the agent instructions so future coding sessions can verify +changes confidently. + +## Seed First Real Workplan + +```task +id: BINKY-WP-0001-T03 +status: todo +priority: medium +``` + +Create the first implementation workplan for the repository's most important +next change. After workplan file updates, run the sync locally from this repo +checkout: + +```bash +statehub fix-consistency +```