coulomb/binky-control

Fork 0

tegwick 67d735ddec Seeded initial INTENT

2026-07-16 02:34:24 +02:00

56 KiB

Raw Blame History

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:

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:

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)

A healthy pattern is:

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)

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:

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)

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) NIST’s AI Risk Management Framework is also useful as a practical structure for identifying and managing AI risks. (NIST)

In your stack, governance should become executable:

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:

ingest company documents, emails, tickets, calendar, repos, accounting exports
maintain a company context graph
list active control loops
show open decisions
show risks and blocked work
draft actions, but not execute sensitive actions
maintain evidence-backed weekly operating review
route follow-ups to people
generate capability maturity snapshots
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.

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.

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.

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

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) LangGraph emphasizes durable execution, streaming, persistence, and human-in-the-loop orchestration. (Docs by LangChain) OpenTelemetry remains the obvious baseline for observability because it standardizes telemetry generation, collection, and export for traces, metrics, and logs. (OpenTelemetry)

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)

12. The first concrete workplan

I would proceed in six steps.

Step 1: Define the operating philosophy

Create:

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:

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:

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:

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:

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.

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:

Blocked: waiting for human input

Your system needs the opposite default:

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:

Agent → asks human → waits → acts

Use this:

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:

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:

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:

Approve / reject / redirect / set policy

not:

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:

Clear decision queue.
Review evidence.
Make priority choices.
Give direction.
Avoid getting dragged into execution.

Your daily dashboard should show only:

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:

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:

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:

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:

# 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:

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:

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:

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

If uncertain, collect evidence and produce a comparison.
Do not ask for clarification unless the ambiguity changes risk or external commitment.

Documentation default

Agents may create and improve internal markdown documents freely.
They must preserve provenance and mark assumptions.

Email default

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

Agents may recommend spending.
Agents may not spend money unless inside an approved recurring budget or explicit threshold.

Product default

Agents may refine specs, use cases, architecture, naming, backlog, and implementation plans.
They may not declare strategic direction final without founder approval.

Code default

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:

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:

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:

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:

# 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:

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:

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

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

Maintain all active projects and repos.
Generate daily or return briefs.
Keep an explicit decision queue.
Classify work into Green / Blue / Yellow / Orange / Red.
Prepare approval packages.
Maintain office-hour runbooks.
Continue safe unattended work.
Record assumptions and evidence.
Track stale decisions.
Suggest next best founder action.

First automation domains

I would choose these three first:

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:

Build capability.
Preserve control.
Find revenue.

12. Updated architecture

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:

Proceeding
Prepared for review
Deferred by policy

Invalid state:

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:

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:

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:

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:

# 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:

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:

Ecosystem ≠ Company

The ecosystem is the capability field.

The company is the commercial operator.

Ecosystem

The ecosystem contains:

Coulomb
Net Kingdom
Railiance
HelixForge-style software factory
Knowledge standards
Infrastructure concepts
Reusable capabilities
Open and internal projects

Its purpose:

Generate, structure, test, and mature capabilities.

Company

Binky Hedgehog GmbH / future Operational Knowledge GmbH exists to:

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:

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:

Coulomb discovers, clusters, matures, and packages reusable capabilities.

Possible commercial angle:

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:

Net Kingdom provides identity, access, security, governance,
and operational sovereignty for agentic and human systems.

Possible commercial angle:

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:

Railiance coordinates reliable workflows, deliveries,
evidence chains, and operational commitments.

Possible commercial angle:

coordination-engine
email-connect
evidence-backed communications
delivery/result tracking
workflow reliability
business process coordination

Railiance is where intentions become fulfilled commitments.

Together:

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.

We help organizations make their operational knowledge visible,
governable, executable, and agent-ready.

Internal mission

Operate itself through the same stack.

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:

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.

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:

The Operational Knowledge Flywheel

or simply:

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:

Company exists legally but has not become the active operating vehicle.

Phase 1 — Reactivation

Goal:

Make the company administratively alive, clean, compliant, and usable.

Focus:

banking
tax/accountant
registered details
bookkeeping
contracts
basic website
email/domain setup
internal company canon
decision records

Phase 2 — Operating company

Goal:

Use the company to sell first products/services.

Focus:

first offer
first customer segment
first invoices
first delivery process
first evidence-backed case studies

Phase 3 — Ecosystem provider

Goal:

Company becomes the provider of products from Coulomb / Net Kingdom / Railiance.

Focus:

product portfolio
support model
pricing model
security posture
repeatable delivery
partner/customer relationships

Phase 4 — Operational Knowledge GmbH

Goal:

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:

Operational Knowledge becomes a category-defining company.

Symbolic marker:

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:

Binky / OK
├── Company Operations
├── Ecosystem Productization
└── Market Development

Company Operations

Purpose:

Make the legal company real, controlled, and operational.

Includes:

finance
accounting
legal
tax
banking
domains
email
contracts
compliance
internal governance

Ecosystem Productization

Purpose:

Turn Coulomb / Net Kingdom / Railiance capabilities into sellable offers.

Includes:

capability registry
product candidates
packaging
pricing
MVP offers
delivery playbooks
dogfood evidence

Market Development

Purpose:

Find customers, validate pain, generate revenue.

Includes:

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.

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:

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:

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:

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:

unclear processes
fragmented configuration
bad access control
weak evidence
implicit decisions
tribal knowledge
tool sprawl
no capability map
no governance

Your offer:

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:

Operational Knowledge Audit

Deliverables:

- 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:

Binky Operational Knowledge Audit v0

Assess:

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:

practical control over the company,
first dogfood evidence,
a reusable audit template,
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:

daily brief
return brief
decision queue
office-hour queue
priority stack

Company Reactivation Agent

Tracks:

tax/accountant tasks
banking tasks
legal form details
domain/email setup
contracts
administrative deadlines

Ecosystem Cartographer

Maps:

Coulomb
Net Kingdom
Railiance
repos
documents
capabilities
maturity
product candidates

Offer Builder

Turns capabilities into:

offers
landing page copy
scope
deliverables
pricing hypotheses
case study structure

Dogfood Archivist

Records:

internal use cases
before/after states
evidence
lessons learned
product implications

Finance Steward

Tracks:

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

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

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

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

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

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

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:

- 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:

Binky Hedgehog GmbH develops operational knowledge infrastructure for agentic, secure, and self-improving organizations.

Later:

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

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.

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

Make Binky Hedgehog GmbH practically operable and strategically aimed at becoming Operational Knowledge GmbH.

First sprint deliverables

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:

# 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

56 KiB Raw Blame History Unescape Escape

Prompt 1: Running a Company

Answer:

1. Start with the company as a system of control loops

2. Define the “agentic stack” in layers

3. Use agent roles, not generic agents

4. Build around registries

5. Separate workflow durability from agent reasoning

6. Standardize tool access

7. Treat governance as product architecture, not bureaucracy

8. Build the first version as an “agentic management cockpit”

9. Use maturity levels for automation

10. Pick a narrow first operating domain

Option A: Founder / management operating loop

Option B: Sales / customer-development loop

Option C: Finance / admin loop

11. Suggested architecture for your context

12. The first concrete workplan

Step 1: Define the operating philosophy

Step 2: Create the Company Control Loop Catalog

Step 3: Build the registries

Step 4: Implement one evidence-backed cockpit

Step 5: Add bounded agents

Step 6: Gradually raise autonomy

My recommended framing

Prompt 2: Unblocking Progress

Answer

1. New design principle: never make “ask Bernd” the default

Adapted model: the Solo-Agentic Company Stack

2. Introduce autonomy lanes

3. Replace “approval needed” with “approval package prepared”

4. Define three operating modes

Mode A: Evening Operator Mode

Mode B: Unattended Autopilot Mode

Mode C: Office-Hour Command Days

5. Change the agent roles

Core agents for a solo-agentic company

6. Create a “founder attention budget”

7. Use default policies to avoid needless blocking

Research default

Documentation default

Email default

Spending default

Product default

Code default

8. Build around queues, not chats

9. Make “absence” an explicit first-class state

10. Reframe the company stack as an asynchronous factory

11. Concrete MVP for your boundary condition

MVP: Solo Founder Autopilot Cockpit

Core artifacts

First capabilities

First automation domains

12. Updated architecture

13. The most important operating rule

14. Example: how daily progress continues without you

15. Suggested autonomy thresholds

16. The founder interface should be brutalist

17. Final adapted framing

Prompt 3: Practical Starting Point

Answer

1. Separate the ecosystem from the company

Ecosystem

Company

2. Define the company thesis

3. Give each ecosystem pillar a role

Coulomb

Net Kingdom

Railiance

4. Make Binky / OK the dogfooding company

External mission

Internal mission

5. Establish the “OK Flywheel”

6. Define Binky Hedgehog GmbH as the transition vessel

Phase 0 — Dormant legal shell

Phase 1 — Reactivation

Phase 2 — Operating company

Phase 3 — Ecosystem provider

Phase 4 — Operational Knowledge GmbH

Phase 5 — OK-level ambition

56 KiB

Raw Blame History

`INTENT.md`

`EcosystemMap.md`

`DogfoodPolicy.md`

`OfferCatalog.md`

`CompanyReactivationPlan.md`

`AutonomyPolicy.md`