Soleur Blog

Skill Libraries vs. Workflow Plugins: Two Shapes of Claude Code Extension

2026-05-15T00:00:00Z

Search "Claude Code skills" on GitHub and two very different shapes come back. One repository is a catalog: a long list of self-contained skills you can drop into any Claude Code install, picked individually, used independently. Another shape is the opposite — a single bundle of agents, skills, and a shared knowledge base, opinionated end-to-end, with cross-references between every component.

The instinct is to rank them on shelf size. The catalog looks bigger, the bundle looks narrower, and the comparison ends before the actual question gets asked: which shape fits the work you're doing?

These are two different categories. Each answers a different question. Choosing between them — or running both — depends on what you need Claude Code to do this week.

What a Skill Library Is

A skill library is a portable catalog of self-contained Claude Code skills. The defining traits: breadth-first coverage, intentional unopinionatedness about how the skills get used, pick-and-mix consumption, MIT-friendly portability across teams and projects.

The canonical exemplar is the alirezarezvani/claude-skills repository — the reference implementation for the portable-library shape. It catalogs a broad collection of skills covering common developer needs (research workflows, data wrangling, documentation generation, project scaffolding) and ships them as independent units. Each skill is its own folder, its own README, its own contract. You can copy one skill into your project, ignore everything else in the catalog, and never touch the rest.

A skill library answers one question: "what's the next useful capability I can add to Claude Code without changing how I work?" The library is a shelf. You walk down it, you take what you need, you go. There is no expectation that skill A is aware of skill B. There is no shared memory between them. Orchestration is your job; the library hands you the pieces.

That shape has real strengths. The library is portable: a skill written for one team's Claude Code install runs on another team's install with no migration. The catalog scales horizontally — adding capabilities widens coverage without changing the core promise. And the unopinionated design respects the user's existing workflow, imposing no convention.

What a Workflow Plugin Is

A workflow plugin is opinionated orchestration across a lifecycle. Where a library hands you pieces, this shape runs an organization.

Soleur is the canonical exemplar. Soleur ships 66+ agents, 73+ skills, and a compounding knowledge base, organized across 8 business departments — engineering, marketing, legal, finance, operations, product, sales, support, community. The agents are not interchangeable parts. The marketing agent reads what the legal agent decided. The competitive-intelligence agent feeds the brand-architect agent. The compound skill captures learnings from every session and replays them into the next one.

The agents and skills are wired through a brainstorm → plan → work → review → compound lifecycle. Each stage is a gate. Brainstorm surfaces ambiguity before plans get written. Plans get deepened, then executed by work. Review catches what work missed. Compound writes the lesson into a knowledge base that every future session reads from. Decisions in session 1 shape what session 50 produces.

The compounding knowledge base is the structural component that separates a workflow plugin from a pile of skills. It is a git-tracked directory of markdown files that every agent reads from and writes to. The brand guide informs the copywriter agent's tone. The competitive-intelligence audit informs the growth-strategist agent's positioning. The institutional learnings from a debugged migration inform the data-integrity-guardian agent the next time someone touches the schema. None of this requires the founder to wire it manually. The cross-domain coherence is the default.

This shape answers a different question: "how do I execute every department of my company without hiring a team?" That is the Company-as-a-Service shape — a full AI organization, opinionated end-to-end, designed for the founder running every job alone.

Why Two Shapes (Not One Hierarchy)

The temptation is to put these on a leaderboard and pick a winner. Resist it. Skill libraries and workflow plugins optimize for different things. Comparing them on the same axis is like comparing a hardware store to a general contractor — same building materials, completely different unit of value.

Optimizes for	Skill libraries	Workflow plugins
Distribution model	Pick-and-mix, individual skills	End-to-end lifecycle, all-or-nothing
Unit of value	A single capability	A coordinated organization
Knowledge flow	Per-skill, ephemeral	Cross-session, compounding
Adoption pattern	Copy what you need	Install once, use everything
Best fit	Augmenting an existing workflow	Replacing the workflow itself

Neither column is a deficiency. The library shape exists because some users have a workflow they like and want more capabilities to drop into it. The workflow-plugin shape exists because some users — solo founders especially — don't have a workflow yet and need one that already works.

The wrong question is "which is better?" The right question is "which one does what I need this week?" Sometimes the answer is one. Sometimes both. Sometimes the answer changes as the work changes.

When a Skill Library Wins

Three founder moments make the portable-library shape unambiguously the right call.

You need one capability, not a system. You're working on something that's mostly working. You need a single skill — clean up an Excel export, normalize a JSON schema, generate boilerplate for a new package. You don't want a new lifecycle. You want a tool you can install in two minutes and forget you have until you need it again. The skill library is the shelf you walk to.

You're evaluating Claude Code itself. If you haven't decided whether Claude Code is the right substrate for your team, you don't want to commit to an opinionated bundle yet. Pulling individual skills from a portable library is a low-risk way to feel out the platform — the cost of removal is one folder. Library skills are evaluation-friendly by design.

You already have an orchestration layer. Some teams have invested years in their own internal workflow — their own brainstorming process, their own QA gates, their own knowledge management. Layering an opinionated lifecycle on top would conflict. A portable library slots in without claiming the orchestration territory.

In each of those cases, the opinionated shape would be the wrong fit. The user already has what it would replace.

When a Workflow Plugin Wins

The other three moments belong to this shape.

You're a solo founder running every department. Marketing campaigns, legal contracts, financial planning, competitive analysis, customer support — every job that a venture-backed company spreads across eight hires. You don't have a workflow that absorbs context across departments because you don't have departments. An opinionated organization is the substitute for the team you didn't hire.

You need decisions to compound. A skill-library session 100 starts where session 1 started — fresh, no memory, no accumulated context. For prototyping that's fine. For running a business it's a structural problem: every session re-litigates what was already decided. A compounding knowledge base means the brand decisions from January shape the marketing copy in May without the founder pasting them back into the prompt.

You want the lifecycle, not only the tools. Brainstorm before plan, plan before work, review before commit, compound before move-on. The lifecycle is opinionated on purpose: it enforces the discipline a solo founder can't enforce on themselves at 11pm before a release. The skills inside are the executors; the lifecycle is the structure that makes the executors useful.

These are the moments where the Company-as-a-Service shape — not a tool, an organization — wins.

They Stack

The two shapes are not mutually exclusive. A founder running Soleur for cross-domain orchestration can install individual skills from a portable library for one-off capabilities the workflow-plugin shape doesn't cover. Different layers of the stack: the organization runs the lifecycle, the library skills fill specific gaps.

The category-creation point holds: choose the shape based on what you need it to do. Run both when both answer different questions.

FAQ

How does alirezarezvani/claude-skills relate to Soleur?

It is the canonical exemplar of the portable-library category — a different shape, answering a different question. Soleur is the workflow-plugin shape. They sit in different categories, not on the same leaderboard.

Can I use both?

Yes. The shapes stack at different layers. The organization runs the lifecycle; library skills fill capability gaps the lifecycle doesn't cover.

Why isn't there a head-count comparison?

Counting catalog entries against a coordinated organization's component list is comparing inventory against architecture. The number of library entries says nothing about whether a lifecycle exists, whether knowledge compounds across sessions, or whether agents share context. The right comparison is shape-against-shape, not count-against-count.

Which shape is right for a solo founder running a company alone?

The workflow-plugin shape. The defining trait of solo-founder work — running every department without a team to absorb context — requires the compounding knowledge base and cross-domain orchestration that a portable library, by design, does not provide. Use a library to augment specific capabilities; use an organization to replace the team you don't have.

What about installing both?

Common and reasonable. The organization should be the substrate; the library can extend specific capabilities the substrate doesn't cover. Order matters: install the workflow plugin first, then layer library skills on top where the gaps appear.

If you're a solo founder building toward the company that takes every job off your plate, the workflow-plugin shape is what you want as the substrate. See how Company-as-a-Service runs every department — and decide where the library skills slot in around it.

How to Run Every Business Department with AI Agents: A Solo Founder's Playbook

2026-05-14T00:00:00Z

You are doing eight jobs. Engineering. Marketing. Legal. Finance. Operations. Product. Sales. Support.

Most founders accept this as a permanent condition of solo-building. More tools help — but the problem is not tool speed. It is tool isolation. Every output from one AI session stops at its session boundary. The marketing tool does not know what the legal tool decided. The engineering agent does not know what the product roadmap changed to. You end up serving as the relay: reading, summarizing, copy-pasting context between systems.

That is not delegation. It is manual coordination with extra steps.

Company-as-a-Service solves a different problem: not how fast each tool works, but whether the outputs connect. When agents share a compounding knowledge base, the legal decision flows into marketing copy before you open a browser tab. The brand guide the marketing agent updated gets read by every content-generation agent on every subsequent task. Every session starts smarter than the last.

This is the playbook for running all eight departments — not faster with isolated tools, but systematically with a connected AI organization.

The Delegation Framework: What AI Agents Own vs. What You Must Own

Effective delegation is not abdication. The founders who get the most leverage from AI agents draw a sharp line between decision and execution. The agent handles the execution surface — research, drafting, analysis, routing, monitoring. The founder sets intent, reviews outputs, and makes the decisions that require judgment, context, or accountability that no system should hold.

Three categories of work:

AI executes fully (with review): Research, first drafts, competitive monitoring, structured analysis, scheduled reports, routine correspondence, document generation from templates, code review, test writing, infrastructure provisioning from specs.

AI executes, founder reviews before finalizing: Legal documents, financial models, outbound messaging, pricing changes, anything that commits the company externally.

Founder owns, AI supports: Strategic positioning, product vision, customer relationships, high-stakes negotiations, anything where your specific judgment is the differentiator.

The goal is to push the first category as far as possible while maintaining genuine control over the second. AI agents produce starting points, not final answers. Your expertise is amplified, not replaced.

Engineering and Product

This is where most founders start — and where AI agents are already most capable.

An AI engineering agent can write, review, and refactor code. It can run tests, open PRs, identify security issues, and monitor for regressions. A product agent can analyze competitors, produce feature specs from requirements, review against the existing roadmap, and document tradeoffs.

The leverage here is throughput. A single founder with an AI engineering organization can run a full brainstorm-plan-implement-review-compound lifecycle on multiple workstreams without losing context between them. The engineering agents remember the architecture decisions. The product agents reference the competitive landscape report from last month. No re-briefing required.

Key delegation surface:

Automated code review on every PR — no manual review backlog
Architecture research and design documents drafted before you open a file
Test suites written in parallel with implementation, not after

What you still own: technical direction, architecture decisions that define years of product surface, and any customer-facing technical commitment.

Marketing

Marketing is where solo founders feel the most time pressure and the most uncertainty. Writing copy, running campaigns, monitoring competitors, planning content, tracking results — each task is a context switch that pulls from engineering time.

An AI marketing organization handles the full operational surface.

Content production: Brand-consistent copy for landing pages, blog posts, email sequences, and social distribution. When the marketing agent reads your brand guide before generating, the output starts closer to final. When it reads prior content, it maintains voice consistency across months of output.

Competitive analysis: Continuous monitoring of competitor announcements, pricing changes, and positioning shifts. The agent runs the search, produces the report, and routes findings to the relevant agents — product, sales, content — without a separate workflow.

SEO and distribution: Keyword research, content gap analysis, technical audits. The work that would require a specialist firm or a junior hire can be scheduled and executed on a cadence, not ad hoc when you have time.

The memory advantage is material here: your marketing agent knows your brand guide. It knows the compliance requirements your legal agent finalized. It knows the pricing your finance agent modeled. Context flows between departments without your relay.

What you still own: strategic positioning, the audience insight that comes from talking to customers, and any campaign commitment that involves material spend.

Legal

The legal function is where solo founders most often either underspend (relying on general-purpose chatbots for contracts) or overspend (retaining firms for work that does not require it).

An AI legal agent covers the operational surface: drafting contracts from standard templates, reviewing agreements against a checklist of known risk vectors, flagging compliance requirements, generating privacy policies and terms of service from your actual data practices, and maintaining a legal document library that every other agent can reference.

When a marketing agent is about to draft copy that makes a product claim, it can reference the legal agent's existing compliance notes before generating. When the product roadmap includes a data feature, the legal agent flags the consent requirements before engineering begins. This is cross-domain coherence — decisions flow between departments without manual routing.

Trust scaffolding applies here most critically: AI legal output is a starting point for review, not a substitute for counsel on material matters. Contracts above a threshold, fundraising agreements, litigation — these require human lawyers. The AI legal agent handles the routine operational surface, not the exceptions.

Finance

Financial operations for a solo founder are both time-consuming and often deprioritized until they cannot be ignored.

An AI finance agent covers: revenue tracking against plan, expense categorization, cash flow modeling, scenario analysis, financial reporting in formats investors or partners expect, and budget-to-actual monitoring. When connected to the rest of the organization, it can update the model when sales closes a deal and alert when burn rate changes materially.

The compounding benefit: the financial model gets more accurate over time as the agent builds familiarity with your business's revenue patterns, seasonality, and cost drivers. The context from last quarter's analysis informs this quarter's forecast without re-briefing.

What you still own: financial commitments, funding decisions, and any reporting that goes to external stakeholders with legal or regulatory consequences.

Operations

Operations is the catch-all department — everything that keeps the company running but does not belong to a named function. Vendor management, infrastructure provisioning, expense tracking, subscription monitoring, process documentation.

An AI operations agent handles: infrastructure provisioning from specs, scheduled maintenance tasks, expense reconciliation, subscription audit, vendor comparison and research, and operational documentation. When infrastructure changes, the operations agent records what changed and why — the context future agents need when something breaks.

The compounding advantage here is documentation. Every decision the operations agent records becomes institutional memory. The system that takes three hours to debug the first time takes fifteen minutes the second time.

Sales and Support

For most solo founders at the early stage, sales is relationship-driven and personal — and should remain so. The AI leverage in sales is in the support infrastructure: competitive battlecards, objection-handling playbooks, proposal templates, pipeline health analysis, and outbound sequence drafts.

Support scales better with AI than almost any other function. FAQ documentation, first-response drafts to common questions, knowledge base management, and issue triage can all be handled by an AI support agent. The agent learns from every interaction — the next time someone asks the same question, the answer is better and the response is faster.

What you still own: relationship-building, strategic partnerships, and any sales situation that requires genuine human judgment about fit.

The Memory Layer: Why Shared Context Across Departments Is the Unlock

Individual department agents are useful. An AI organization is transformative.

The difference is the knowledge base. When agents share a compounding knowledge base — a structured store of decisions, documents, competitive intelligence, and institutional context — the output of every department informs every other department. The legal agent's compliance analysis is available to the marketing agent before it writes a lead generation sequence. The product agent's competitive landscape update reaches the marketing agent before it plans the next campaign. The finance agent's runway model is visible to the product agent when it is evaluating a six-month roadmap.

This is what knowledge compounding means in practice: each task starts from a more informed baseline than the last. Over time, the AI organization gets smarter about your business — not because the models improved, but because the context they have access to grew.

Month one looks like fast tools. Month six looks like an organization.

Getting Started: Your First Two Weeks

The compounding benefit starts accumulating from day one, but only if the foundation is right.

Week 1: Establish the knowledge base. Before delegating any task, invest in capturing what you know. The brand guide, the competitive landscape, the product positioning, the legal constraints you are already aware of, the financial model. This is the starting context that turns generic AI output into company-specific output.

Days 3–7: Start with the highest-pain department. For most founders, that is marketing or legal. Pick one department, delegate a full task — not a subtask — and review the output. The goal is not a perfect first output. It is establishing the delegation muscle and identifying the gaps in the knowledge base.

Week 2: Add the knowledge routing. The real leverage emerges when the output from week one's delegated tasks starts feeding the next ones. The competitive analysis the marketing agent produced goes into the knowledge base. The contract template the legal agent drafted becomes the template for future deals. Each output compounds.

The tasks AI cannot yet handle — strategic positioning, genuine customer insight, high-stakes judgment calls — get clearer as delegation expands. The founder role shifts from executor to decision-maker. That is the organization you are trying to build.

Frequently Asked Questions

How long does it take to set up AI agents for every business department?

The initial knowledge base setup takes 2–4 hours depending on how much existing documentation you have. Delegating the first full task per department typically takes one to two weeks. The compounding benefit — where agents get meaningfully smarter about your business — becomes noticeable by month two or three.

Do I need to be technical to run a business with AI agents?

For marketing, legal, finance, operations, and support agents, no technical background is required. The setup is primarily about documenting what you know about your business so agents have the right context. Engineering agents benefit from technical depth in the founder, since review and direction work requires domain knowledge.

What happens when an AI agent makes a mistake?

AI agent output should always be reviewed before external use — agents produce starting points, not final answers. When an agent makes an error, the correction goes back into the knowledge base so the same mistake does not repeat. Over time, the correction layer becomes part of the institutional memory the agent draws on.

How is running departments with AI agents different from using a general-purpose chatbot?

General-purpose chatbots are stateless — each session starts from zero, with no memory of your business, prior decisions, or existing documentation. An AI organization built on a compounding knowledge base starts each session with the full context of everything prior agents have done. The legal agent knows the compliance decisions made six months ago. The marketing agent knows the brand positioning refined last quarter. That accumulated context is what separates a tool from an organization.

Which department should I delegate to AI agents first?

Start with the department where you feel the most time pressure and the least strategic value from doing the work yourself. For most solo founders, that is marketing content production or legal document generation. Both have clear delegation surfaces, reviewable outputs, and immediate time savings. Engineering delegation can run in parallel if you are already technical.

What Is Company-as-a-Service?

2026-05-12T00:00:00Z

The acronym CaaS has meant Container-as-a-Service for cloud infrastructure teams for years — Kubernetes, EKS, managed runtimes. That definition still holds. But a second, structurally larger meaning is emerging: Company-as-a-Service.

This article is about the second kind.

The Problem That Predates the Solution

Running a company requires eight distinct functions: engineering, marketing, legal, finance, operations, product, sales, and support. Each demands domain expertise. Each generates decisions. And decisions in one domain constrain every other — the legal strategy limits marketing campaigns, the financial model drives the product roadmap, the engineering architecture defines operational complexity.

For most of business history, the only way to hold that coordination surface was to hire people who talked to each other. The organization was the coordination system. More functions meant more people. Headcount scaled with the company's surface area.

The solo founder faced a structural ceiling — not a lack of intelligence or drive, but a coordination bottleneck. You cannot review your own code, run your own marketing campaigns, draft your own contracts, and build your own product simultaneously. Time is finite. Attention fragments. Things fall through the gaps.

AI tools softened the ceiling. Coding assistants accelerated engineering. General-purpose models drafted copy. But the ceiling did not disappear. Each tool solved a fragment. None solved the coordination.

Company-as-a-Service is the architecture that addresses the deeper problem.

What Company-as-a-Service Actually Is

Company-as-a-Service is a platform architecture in which AI agents run every business department — marketing, legal, finance, operations, product, engineering, sales, support — and share a single compounding knowledge base.

The key word is share.

Most AI tools are stateless. Session one and session one hundred start from the same blank context. The marketing agent does not know what the legal agent decided. The product agent has no visibility into what the engineering agent already built. Every function operates in isolation, and the founder pays the integration cost in time, context-switching, and dropped threads.

A CaaS platform breaks this pattern. When the legal agent drafts a contract, that decision enters the shared knowledge base. When the marketing agent writes copy, it references the brand guide the brand-architect agent already established. When the engineering agent ships a feature, the product agent's spec is already in context.

The company has memory. The founder makes decisions. The system executes — and compounds.

The Three Properties That Define the Category

Not every multi-agent platform qualifies as Company-as-a-Service. Three properties separate the category from adjacent tools:

1. Full-Spectrum Domain Coverage

A CaaS platform covers every function a company needs to operate — not just engineering, not just marketing. The test: can a solo founder delegate legal review, run a marketing campaign, model financial scenarios, manage competitive intelligence, and ship a feature without switching platforms?

Partial coverage is a copilot. Full coverage is an organization.

2. Cross-Domain Knowledge Coherence

Agents must share context. The legal agent should know the brand voice. The marketing agent should know the compliance constraints. The financial agent should know the product roadmap. Without cross-domain coherence, a multi-agent platform is just several isolated tools installed in the same interface.

Knowledge coherence is what makes compounding possible. Every decision, document, and learned pattern routes back into the shared knowledge base. The system gets smarter with every task — not because the models improved, but because the institutional memory accumulated.

3. Founder-in-the-Loop Authority

A CaaS platform amplifies founder judgment — it does not replace it. The founder remains the decision-maker. Agents execute with domain expertise and full context, but they do not override the human at the top of the hierarchy.

This is the distinction from fully autonomous AI companies. The founder's judgment is not a bug in the human-AI relationship. It is the product's core value proposition.

How Soleur Implements CaaS

Soleur is the open-source CaaS platform. The architecture has three layers:

Agents are AI specialists, each with deep expertise in a specific domain or function. Soleur ships 60+ agents across all eight business departments. Domain leaders (CMO, CTO, CFO, CLO, COO, CPO, CRO, CCO) orchestrate specialist teams within each domain. These are not chatbots — they are stateful, tool-using, multi-step executors that produce real artifacts: code, contracts, campaigns, financial models.

Skills are compound workflows — sequences of agent invocations, tool calls, and decision gates that accomplish structured tasks. The brainstorm skill runs a multi-agent requirements workshop. The plan skill produces an implementation plan with risk analysis. The compound skill captures learnings after every session and routes them back into the knowledge base. There are 60+ skills covering the full brainstorm-plan-implement-review-compound lifecycle.

The knowledge base is the compounding layer — a git-tracked directory of markdown files that agents read and write as they work. It contains brand guides, competitive intelligence, financial models, architectural decisions, legal templates, and captured learnings from every prior session. No vector database. No embeddings. No black box. The knowledge base is a directory the founder can open, read, and edit directly.

When these three layers operate together, the result is an organization that learns. A solo founder running Soleur in month six operates with qualitatively more leverage than in month one — not because the models improved, but because the knowledge base accumulated.

CaaS vs. Everything Else

The market has several categories that look adjacent. None of them are the same thing.

AI assistants (ChatGPT, Claude.ai, Gemini) are stateless, general-purpose, session-scoped. No business context. No domain specialization. No memory between sessions. Excellent for one-off tasks; structurally incapable of running a company.

AI coding assistants (Cursor, GitHub Copilot) solve the engineering slice — the fraction of a company's work that involves writing code. They are increasingly sophisticated within that domain. They do not run marketing campaigns, draft contracts, or model financial scenarios.

Agent frameworks (CrewAI, AutoGen, LangGraph) provide primitives for building multi-agent systems. They are developer tools that require the user to architect agents, define workflows, build the knowledge layer, and maintain infrastructure. CaaS is the finished product built on those primitives.

Fully autonomous AI companies attempt full autonomy — the system makes decisions without founder involvement. Soleur explicitly rejects this model. Founder judgment is the product's core value, not a limitation to engineer around.

What a Solo Founder Can Actually Delegate

With a CaaS platform operational, the surface area a solo founder can manage increases by an order of magnitude. Concretely:

Marketing: Campaign planning, copy drafts, competitive analysis, SEO audits, social distribution — delegated to the CMO and its eleven specialist agents
Legal: Contract drafts, compliance audits, GDPR gate checks, legal document generation — delegated to the CLO
Engineering: Architecture review, code review, test design, security scanning, performance analysis — delegated to the CTO and its review team
Finance: Budget planning, revenue forecasting, burn rate modeling — delegated to the CFO
Operations: Vendor research, expense tracking, infrastructure planning — delegated to the COO
Product: Requirements analysis, UX audits, competitive intelligence, business validation — delegated to the CPO

What remains with the founder: decisions, priorities, judgment calls, and relationships — the things that actually require being human.

The Compounding Effect

The most important property of Company-as-a-Service is not what it does on day one. It is what it does on day three hundred.

Every session captures learnings. Every document produced enters the knowledge base. Every decision made becomes available context for the next decision. The system does not reset. It accumulates.

This is the mechanism behind the prediction. Dario Amodei, CEO of Anthropic, forecast that a one-person billion-dollar company would emerge as soon as 2026 — not as a curiosity but as a structural outcome of AI agents extending beyond engineering into every function a company needs. The solo founder building with a CaaS platform today is not waiting for that future. They are already inside it.

What is Company-as-a-Service (CaaS)?

Company-as-a-Service is a platform architecture where AI agents run every business department — marketing, legal, finance, engineering, operations, product, sales, and support — and share a single compounding knowledge base. Unlike a copilot or assistant, a CaaS platform covers the full organizational surface and enables cross-domain coordination through persistent, shared context.

How is Company-as-a-Service different from a multi-agent framework?

Agent frameworks like CrewAI or LangGraph provide primitives for building multi-agent systems. They are developer tools that require the user to architect agents, define workflows, build the knowledge layer, and maintain infrastructure. Company-as-a-Service is the finished product — pre-built agents, skills, and a compounding knowledge base ready to run every business department out of the box.

Does a CaaS platform replace the founder?

No. Soleur's model is founder-in-the-loop: the founder makes decisions, agents execute with domain expertise and full business context, and outputs return for human review. Agents handle the execution volume. Judgment stays human.

What is the knowledge base in a CaaS platform?

The knowledge base is a git-tracked directory of markdown files that agents read and write as they work. It stores brand guides, competitive intelligence, financial models, architectural decisions, legal templates, and learnings from every prior session. It is not a black box — the founder can open, read, and edit it directly. Over time it becomes the institutional memory of the company.

What departments does Soleur cover?

Soleur covers all eight business departments: engineering, marketing, legal, finance, operations, product, sales, and support. Each domain has a leader agent (CTO, CMO, CFO, CLO, COO, CPO, CRO, CCO) that orchestrates a specialist team within the department.

Soleur vs. CrewAI: AI Agent Framework vs. AI Organization

2026-05-07T00:00:00Z

CrewAI is frequently searched alongside Soleur, which is notable because the two are not in the same category. CrewAI is a Python framework for building custom multi-agent AI systems. Soleur is the Company-as-a-Service platform — 66 agents, 73 skills, and a compounding knowledge base organized across 8 business departments.

Comparing them is legitimate only as a decision-making exercise: a solo founder evaluating both is deciding whether to build multi-agent infrastructure with CrewAI or deploy the pre-built AI organization that Soleur provides. That is a real choice with real tradeoffs.

What CrewAI Actually Is

CrewAI is an open-source Python framework, founded by João Moura in 2023, that enables developers to build custom multi-agent AI systems. With over 45,000 GitHub stars, it has become one of the most widely adopted multi-agent frameworks in the Python ecosystem.

The framework provides primitives for defining agents with specific roles, goals, and backstories; assigning tools to agents; and structuring the relationships between agents — whether sequential (one agent feeds the next) or hierarchical (a manager agent routes work to specialists).

A CrewAI crew is something a developer builds. You define the agents, specify their tools, set the process, and deploy the resulting system. The framework is unopinionated about what the crew does — a developer could build a research pipeline, a content production system, an engineering review workflow, or a financial analysis system. The primitives are general-purpose; the application is defined entirely by the developer.

CrewAI also offers CrewAI AMP, a managed cloud platform that hosts and scales custom crews without requiring self-managed infrastructure. CrewAI Flows provides event-driven and stateful orchestration for complex multi-agent sequences.

What Soleur Actually Is

Soleur is the Company-as-a-Service platform. 66 agents, 73 skills, and a compounding knowledge base organized across 8 business departments — engineering, marketing, legal, finance, operations, product, sales, support, and community.

No assembly required. The agent organization exists the moment the plugin is installed. The legal agent drafts contracts. The competitive intelligence agent maps the market. The engineering agents run the brainstorm-plan-implement-review-compound lifecycle. The financial agents model revenue and track expenses. The brand-architect agent defines brand identity that every downstream marketing agent inherits.

The compounding knowledge base is the structural component that does not exist in CrewAI's framework model: a git-tracked directory of Markdown files that agents write to and read from across sessions. Decisions made in session 1 shape what agents produce in session 50. Cross-domain intelligence is the default, not a custom integration.

The Build vs. Deploy Distinction

This is the decision axis. CrewAI asks: "What multi-agent system do you want to build?" Soleur asks: "What work does your company need to execute?"

A developer using CrewAI starts with a blank framework and constructs exactly the agent system their use case requires. The ceiling is high — any multi-agent workflow expressible in Python is theoretically buildable. The floor requires engineering. Defining agents, wiring tools, testing process flows, deploying infrastructure, and iterating on failure modes is work before the work gets done.

Soleur starts from the other direction. The agents exist. The skills are documented. The domain coverage is pre-built. A solo founder installs the platform and asks the legal agent to review a vendor contract, the marketing agent to run competitive analysis, and the engineering agents to plan a feature — on day one, without building anything.

The tradeoff is real: CrewAI's flexibility means you can build exactly what you need. Soleur's pre-built coverage means you cannot extend it with the same degree of control a custom framework allows. But for most solo founders, the bottleneck is not having a custom multi-agent framework — it is having enough organizational capacity to get the work done.

Where They Differ

What You're Getting

CrewAI: a Python framework. Primitives for building multi-agent systems — agent definitions, tool assignments, process structures, flow orchestration. The output of using CrewAI is a custom-built multi-agent system.

Soleur: a pre-built AI organization. 66 agents across 8 departments, ready to run within the Claude Code environment. The output of using Soleur is organizational execution across business domains.

Required Investment

CrewAI: engineering investment upfront. Defining agents, integrating tools, testing and debugging agent interactions, deploying the resulting system. The framework reduces implementation complexity but does not eliminate it.

Soleur: installation. The organization is available immediately. Ongoing investment is in decision quality — providing judgment at the gates the agents surface — not in building the infrastructure.

Knowledge Persistence

CrewAI: per-crew, per-session by default. Memory capabilities depend on what the developer builds — there is no built-in compounding knowledge base that persists across all sessions and domains out of the box. Integrating persistent cross-session memory requires custom implementation.

Soleur: cross-domain, cross-session by design. The compounding knowledge base accumulates organizational intelligence across all departments. When the legal agent documents a compliance requirement, the engineering agents reference it. When the competitive intelligence agent maps the market, the product agents incorporate it into the roadmap. Memory is structural, not optional.

Target User

CrewAI: developers building custom multi-agent systems. The target is an engineer who needs to orchestrate AI agents for a specific workflow and wants a framework that handles agent coordination, tool use, and process definition.

Soleur: solo founders replacing a full organizational structure. The target is a founder who needs marketing, legal, finance, engineering, operations, product, sales, support, and community work executed — and wants agents that already know how to do those jobs.

Open Source Model

CrewAI: open-source framework (MIT license), with CrewAI AMP as a managed cloud tier. The framework can be self-hosted and extended.

Soleur: open-source platform (Claude Code plugin). Both the agent definitions and skill implementations are inspectable and extendable. Your costs are the Claude API credits your workflows consume.

Ecosystem

CrewAI: large developer ecosystem. The framework's GitHub repository has accumulated significant community contributions, tool integrations, and example crews across diverse use cases.

Soleur: purpose-built for the Company-as-a-Service use case. The ecosystem depth is vertical — 66 agents covering every business domain — rather than horizontal across arbitrary use cases.

When CrewAI Is the Right Choice

CrewAI is the right choice when the problem is building a custom multi-agent system for a specific workflow that does not map to an existing product. A company that needs a specialized research pipeline, a domain-specific content generation system, or a bespoke data-processing agent workflow — where the exact behavior needs to be defined at the framework level — should build with CrewAI rather than adapt a pre-built product.

CrewAI also makes sense when the primary requirement is integrating with existing Python infrastructure. The framework's Python-native design integrates naturally into existing codebases, CI/CD pipelines, and data workflows.

And if the goal is understanding how multi-agent systems work at the framework level — agent coordination, tool use, and process design from first principles — CrewAI's primitives are the appropriate starting point.

When Soleur Is the Right Choice

Soleur is the right choice when the problem is organizational capacity, not infrastructure. A solo founder who needs the work done across multiple business domains — not the framework to build the system that does the work — gets organizational execution from day one.

The compounding knowledge base is the differentiator that CrewAI cannot replicate without custom engineering. A founder whose legal agent documents compliance requirements that the engineering agents subsequently reference — without any custom integration work — gets cross-domain intelligence as a default behavior.

And for founders who do not want to spend engineering time building agent infrastructure before using it, the pre-built organizational model eliminates the build-before-run problem entirely.

Dimension	CrewAI	Soleur
What it is	Python framework	Pre-built AI organization
Setup required	Significant (agent design, tool wiring, deployment)	Minimal (plugin install)
Business domain coverage	Build-your-own	8 departments, pre-built
Cross-domain knowledge base	Custom implementation required	Built-in, compounding
Target user	Developers building custom agent systems	Solo founders needing org capacity
Language requirement	Python	None (Claude Code native)
Open source	Yes (MIT)	Yes
Pricing	Free (framework) / CrewAI AMP (cloud)	Free (API costs)

FAQ

Q: Can CrewAI and Soleur be used together?

Yes, at different layers. A developer could build custom CrewAI crews for specialized workflows that extend beyond Soleur's domain coverage, while using Soleur's pre-built agents for standard business operations. They operate in different environments — CrewAI in Python, Soleur in Claude Code — so integration would require bridging the two surfaces. For most solo founders, the organizational coverage Soleur provides makes building supplemental crews unnecessary.

Q: Is CrewAI a competitor to Soleur?

Only in the sense that a founder might search both when evaluating multi-agent AI options. The categories are different: CrewAI is developer infrastructure for building multi-agent systems; Soleur is a pre-built AI organization for running a company. A founder choosing between them is choosing between building organizational capacity and deploying it.

Q: Does Soleur use a framework like CrewAI internally?

Soleur is built on Claude Code's agent SDK rather than a general-purpose Python framework. Agents are defined as structured Markdown files with frontmatter routing metadata; skills are sequential workflow documents that the Claude Code runtime interprets. The architecture is filesystem-native and human-readable — every agent definition and skill is a file the founder can read, edit, and extend.

Q: What if I need capabilities Soleur doesn't have?

Soleur is open-source. Agent and skill definitions are Markdown files in the plugin directory — inspectable, editable, and extensible. Adding a new agent or skill follows the same pattern as the existing ones. The plugin loader discovers new agents automatically. For truly custom workflow requirements that need Python integration and arbitrary tool access, CrewAI's framework model is the appropriate choice.

Soleur vs. Tanka: Memory AI vs. Execution Intelligence

2026-05-05T00:00:00Z

Both Tanka and Soleur make the same surface claim: AI that never forgets. Tanka markets itself as your "AI co-founder with long-term memory" — a memory-native platform that captures everything your team has said, decided, and discussed across Slack, Gmail, Notion, and WhatsApp. Soleur is the Company-as-a-Service platform — 66 agents, 73 skills, and a compounding knowledge base organized across 8 business departments.

The memory claim is where the similarity ends. What each system remembers, and what it does with that memory, reveals two categorically different tools.

What Tanka Actually Is

Tanka is a memory-native AI messenger for teams. Its core technology — EverMemOS, launched in September 2025 — connects to existing communication tools and turns past conversations into searchable, persistent organizational memory. When a founder needs to recall what was discussed in a meeting three weeks ago, or surface a decision buried in a Slack thread, Tanka retrieves it.

The platform's Memory Transfer feature moves role-specific knowledge between teammates. Tanka's AI Smart Reply drafts context-aware messages based on what the system knows about past conversations. The Fundraising Agent, launched in September 2025, helps founders draft pitch materials, practice investor interviews, and request warm introductions through a venture capital network partnership.

Tanka positions this as "AI co-founder" functionality: it is the company's memory layer — a searchable record of everything the team has ever communicated. EverMemOS claimed a Locomo score of 92.3% at launch, which Tanka described as the highest reported benchmark result for long-context memory systems at the time.

What Soleur Actually Is

The compounding knowledge base is not a record of what was said. It is a git-tracked directory of Markdown files — architectural decisions, brand guidelines, competitive analyses, legal compliance requirements, financial models, and product roadmaps — that agents read and write to with every session. When the legal agent documents a compliance requirement, the engineering agents reference it before building. When the brand-architect agent defines the brand guide, every piece of marketing copy reflects it. When the competitive intelligence agent updates the market landscape, the product agent incorporates it into the roadmap.

Every decision the founder makes becomes institutional memory that the entire organization inherits. The twenty-first session benefits from everything the previous twenty sessions produced.

Communication Memory vs. Execution Memory

This is the architectural distinction that determines which tool solves your actual problem. Tanka captures what was communicated. Soleur captures what was decided and executes on it.

Tanka's memory is retrievable: search for a past conversation, recall a decision buried in an email thread, avoid re-explaining context to a new team member. It solves organizational amnesia — the cost of re-finding and re-explaining information that already exists somewhere in the company's communication history.

Soleur's memory is generative: the legal compliance requirement documented in session 4 changes what the engineering agents build in session 19. The competitive analysis from session 7 shapes the product roadmap in session 12. The brand guide written in session 1 governs every marketing asset produced from that point forward. The memory does not just retrieve — it influences every subsequent execution.

A solo founder using Tanka has a searchable record of everything their team discussed. A solo founder using Soleur has an organization that gets smarter with every decision they make.

The Solo Founder Problem Each Solves

Tanka's primary value proposition is team memory. The platform is designed for teams: Memory Transfer explicitly moves knowledge between teammates; AI Smart Reply drafts messages in a team communication context; the pricing structure (free under 50 users, $299/month for teams of 50+) reflects a team-centric model.

A solo founder without a team gets the memory retrieval capability, but the team-collaboration features have no team to collaborate with. Tanka's planned Agent Store will extend functional agents for GTM, hiring, and product management into the platform — narrowing the execution gap for those specific domains. But the agents are downstream of the memory layer. The communication infrastructure is the primary product.

Soleur is built specifically for one person replacing an entire organization. The brainstorm-to-ship lifecycle runs a solo founder through the work that a CEO, CMO, CLO, CFO, COO, CPO, CRO, and CCO would collectively handle — not by retrieving what was said, but by executing what needs to be done. Legal contracts get drafted. Competitive analyses get run. Financial models get built. Engineering reviews get completed. The founder provides judgment at decision gates. Agents handle execution.

Where They Differ

Memory Architecture

Tanka: communication-layer memory. EverMemOS connects to Slack, Gmail, Notion, and WhatsApp and makes conversation history searchable and retrievable. Memory lives in what the team communicated.

Soleur: execution-layer memory. A git-tracked knowledge base that agents write to and read from across sessions. Memory lives in what was decided, built, and learned — not in conversation logs, but in structured artifacts that directly influence future agent behavior.

Primary Use Case

Tanka: recalling and surfacing past conversations and decisions for teams. Making organizational memory searchable.

Soleur: executing work across 8 business domains with agents that compound organizational knowledge with every session.

Agent Scope

Tanka: Fundraising Agent (September 2025), with GTM, hiring, and product management agents in the roadmap Agent Store.

Soleur: 66 agents across 8 departments — engineering, marketing, legal, finance, operations, product, sales, support, and community — running in the founder's development environment with access to the full compounding knowledge base.

Platform Model

Tanka: memory-native AI messenger. The foundation is communication infrastructure; agents are the extension layer.

Soleur: execution-native AI organization. The foundation is agent-driven workflow; the knowledge base is the compounding memory layer.

Pricing

Tanka: free for teams under 50 users. $29/month (Plus), $199/month (Pro) for individuals with higher credit allocations. $299/month for teams of 50 or more.

Soleur: open-source, free platform. Your costs are the Claude API credits the agents consume.

Who It Is Built For

Tanka: teams dealing with organizational amnesia — distributed teams and growing startups where knowledge management across communication tools is the bottleneck.

Soleur: solo founders who need to replace a full organization with AI — not to remember what was said, but to execute what needs to be done across every department.

When Tanka Is the Right Choice

If the primary problem is organizational memory across a distributed team — critical decisions getting lost in Slack threads, new team members needing to reconstruct context that already exists, cross-tool conversation history being unsearchable — Tanka addresses that problem directly.

Tanka also makes sense if the workflow is already centered on team messaging and communication tools and the value needed is memory layered on top of that existing infrastructure. EverMemOS's approach to making communication history retrievable and actionable is purpose-built for this.

When Soleur Is the Right Choice

If the bottleneck is not memory retrieval but execution across multiple business domains — legal work that does not get done, competitive analysis that never happens, financial models that are not built, engineering that ships without code review — Soleur covers the work, not just the memory of the work.

Solo founders without a team get the full value of Soleur's agent organization from day one. There is no team-collaboration layer to route around — the agents execute directly from the founder's judgment.

And when execution produces institutional memory — when the legal agent documents a compliance requirement that shapes what engineering builds next — that memory is generative, not retrievable. It does not surface the past. It improves the future.

What you need	Tanka	Soleur
Searchable conversation history	Yes	No
Memory across Slack, Gmail, Notion	Yes	No
AI Smart Reply for team messaging	Yes	No
Memory Transfer between teammates	Yes	No
Fundraising Agent	Yes	No
Pre-built agents for legal, marketing, finance	No	Yes
Cross-domain compounding knowledge base	No	Yes
Full workflow lifecycle (brainstorm through ship)	No	Yes
Solo-founder-first design	No	Yes
Open-source	No	Yes
Pricing	Free (<50 users) / $29–199/mo	Free (API costs)

FAQ

Q: Can Tanka and Soleur be used together?

Yes, with distinct roles. Tanka handles communication memory — making team conversations and decisions retrievable. Soleur handles organizational execution — running agents across legal, marketing, finance, engineering, and other domains. A founder with a small team could use Tanka to index communication history while using Soleur for the cross-domain execution work. The knowledge bases serve different functions: Tanka's is communication-derived; Soleur's is decision-derived.

Q: Tanka claims to be an "AI co-founder." What does that mean in practice?

Tanka's "AI co-founder" positioning refers to its persistent memory: unlike most AI tools that forget past conversations, Tanka retains organizational context across sessions. A co-founder who remembers everything discussed is the framing. In practice, Tanka retrieves and surfaces past information rather than executing new work. The co-founder metaphor describes the memory persistence, not the execution breadth.

Q: How does Soleur's knowledge base differ from Tanka's memory?

Tanka's memory captures what was communicated — conversations, messages, and documents that already exist in tools like Slack and Gmail. Soleur's knowledge base captures what was decided and why — brand guides, competitive analyses, architectural decisions, compliance requirements, financial models — as structured artifacts that agents write to and reference in future sessions. Tanka surfaces what already happened; Soleur's knowledge base changes what happens next.

Q: Does Tanka's planned Agent Store change the comparison?

Tanka's planned Agent Store will extend functional agents for GTM, hiring, and product management into the platform. When shipped, this will narrow the execution gap for those specific domains. It will not address the cross-domain coherence that Soleur's compounding knowledge base provides — an agent built on top of a communication memory layer operates from what was said, not from the accumulated organizational intelligence that Soleur's cross-department knowledge base produces.

Best Claude Code Plugins 2026: The Extensions Worth Installing

2026-04-30T00:00:00Z

The official Claude Code plugin marketplace crossed 100 reviewed plugins by early 2026. The community ecosystem is larger still — claudemarketplaces.com tracks 4,200+ skills and 770+ MCP servers as of April 2026. The problem is no longer finding plugins. It is knowing which ones earn the context window space they consume at every session start.

This guide covers the extensions that earn their keep, the evaluation framework you should apply before installing anything, and the distinction between adding a specialized workflow versus replacing the full overhead of running a company.

How to Evaluate a Claude Code Plugin

Every installed plugin loads into your context window at session start. That cost is not theoretical — it accumulates, compresses prior context, and reduces what Claude can hold from your actual project. Before installing, three questions:

Do you use this workflow at least weekly? If not, the context tax is not worth it.
Does the plugin bundle MCP servers? Claude Code's MCP Tool Search (lazy loading) reduces tool definition context use by up to 95%, so MCP-heavy plugins cost less than they used to. Skill text still loads eagerly.
Is the capability bespoke, or would a one-line CLAUDE.md instruction achieve it? Many "plugins" are three-line system prompt additions. The real ones restructure what the agent can do.

With that framework, here are the plugins that survive the filter in 2026.

The Best Claude Code Plugins in 2026

1. Context7 — Live Documentation Access

The single most broadly useful documentation plugin in the ecosystem. Context7 provides real-time, version-accurate documentation for libraries and frameworks. Without it, Claude Code is constrained to its training cutoff — a meaningful problem for fast-moving ecosystems (React 19, Next.js 15, Tailwind v4, Rails 8) where the API surface has shifted since the model was trained.

Why it earns its keep: Hallucinated API signatures are the most common cause of wasted iteration in agentic coding sessions. Context7 eliminates the category. Among the official marketplace plugins, it consistently ranks among the most widely adopted documentation-class extensions.

claude plugin install context7@claude-plugins-official

2. frontend-design — Design Intelligence for UI Work

The frontend-design plugin adds aesthetic judgment that the base model lacks by default: typography hierarchy, color palette coherence, layout density decisions. The difference is visible immediately — before the plugin, AI-generated UIs look like textbook CRUD. After, they look like someone with design opinions built them.

It is consistently one of the most-installed plugins in the official marketplace, ranking at the top of install charts tracked by independent directories.

Why it earns its keep: Design feedback is expensive to source externally. For solo builders shipping UIs without a designer, this is the nearest approximation the ecosystem currently offers.

claude plugin install frontend-design@claude-plugins-official

3. code-review — Parallel Review Agents

The code-review plugin runs multiple specialized review agents in parallel against a pull request — security, performance, style, correctness — and synthesizes findings with confidence scores. Standard Claude Code review happens serially in a single context. This plugin structures it as parallel expert opinions.

For solo engineers who cannot afford a review from a senior colleague on every PR, the parallel agent model is a meaningful upgrade over the default.

claude plugin install code-review@claude-plugins-official

4. Playwright — Browser Automation in the Coding Session

Playwright connects Claude Code directly to a Chrome instance. The agent navigates, fills forms, runs assertions, and debugs on a live page without leaving the coding session. For frontend development and QA workflows, this eliminates the context switch between writing code and verifying it in the browser.

claude plugin install playwright@claude-plugins-official

5. Figma MCP — Design-to-Code Without the Translation Layer

The Figma plugin gives Claude Code direct read access to your design files — components, tokens, layout specs — from the source instead of from screenshots or verbal descriptions. For teams where design and engineering are handled by one person, this closes the biggest handoff gap in the stack.

claude plugin install figma@claude-plugins-official

6. security-guidance — Passive Vulnerability Scanning

The security-guidance plugin hooks into file edit events and scans for vulnerabilities as Claude writes code: command injection, XSS, input validation gaps. It does not require an explicit review step. For anyone shipping code to production without a dedicated security review process, it is a baseline install.

claude plugin install security-guidance@claude-plugins-official

7. GitHub MCP — Issue and PR Management In-Session

The official GitHub plugin lets Claude Code read and write issues, pull requests, and repository metadata without leaving the terminal session. For solo builders managing a backlog alone, collapsing the context switch between the terminal and the browser removes a real friction point.

claude plugin install github@claude-plugins-official

The Different Question: What About the Full Organization Layer?

Everything above extends Claude Code for a specific capability — better documentation access, better UI generation, better code review. Each plugin is a better tool for one job.

There is a different class of extension that does not improve one job. It replaces the eight jobs a solo founder does in a week. Not just coding: marketing, legal, competitive intelligence, financial planning, operations, product strategy, customer support. All of it, with a shared knowledge layer across domains so that every agent knows what every other agent decided.

That is what Soleur is. Not a plugin in the same category as Playwright or Figma — a Company-as-a-Service platform that runs as a Claude Code extension. 60+ agents across eight business departments. 60+ skills that run the full engineering lifecycle from brainstorm to production. A compounding knowledge base that makes each task inform every task that follows.

The distinction is not subtle: the plugins above make you better at the things you are already doing. Soleur changes the scope of what you can do alone.

claude plugin install soleur

The install is one command. What ships behind it is an AI organization that reviews your code, drafts your contracts, monitors your competitors, tracks your pipeline, and compounds its knowledge of your business with every task.

What to Skip

A few categories fail the weekly-use filter for most workflows:

Productivity scaffolding plugins (daily standups, meeting note formatters, time trackers) — these are CLAUDE.md instructions, not plugins. They do not warrant the permanent context overhead.

Duplicate LSP coverage — if your IDE already runs a language server for Go, Java, or C#, the corresponding Claude Code LSP plugin adds load without new capability. Install only if you work in environments where the IDE LSP is unavailable.

Omnibus "connect to everything" automation plugins — plugins that expose hundreds of tools across dozens of services load that entire surface area into context whether or not you are using any of it. Prefer targeted MCP integrations (Stripe, Cloudflare, Vercel, GitHub) over broad connectors.

The Stack Worth Running

For a solo technical founder, the practical install list looks like this:

Plugin	Use case	Install
context7	Live docs for any library	`claude plugin install context7@claude-plugins-official`
frontend-design	UI generation with design judgment	`claude plugin install frontend-design@claude-plugins-official`
code-review	Parallel multi-agent PR review	`claude plugin install code-review@claude-plugins-official`
playwright	Browser automation in-session	`claude plugin install playwright@claude-plugins-official`
github	Issue and PR management	`claude plugin install github@claude-plugins-official`
soleur	Full AI organization across all departments	`claude plugin install soleur`

The first five make the engineering workflow faster. The last one changes what one person can build.

FAQ

What is a Claude Code plugin?

A Claude Code plugin is an extension that bundles custom slash commands, specialized agents, skills, hooks, and MCP server integrations into a single installable unit. When installed, plugins extend Claude Code with domain knowledge, tool connections, or workflow automation. The official Anthropic marketplace hosts 100+ reviewed plugins across development, security, cloud, and productivity categories.

What is the difference between a Claude Code plugin, a skill, and an MCP server?

A plugin is the container — it can bundle all three. A skill is a workflow the agent follows to complete a structured task (e.g., a code review lifecycle or a content generation pipeline). An MCP server connects the agent to an external tool or API (e.g., Stripe, GitHub, Cloudflare). A plugin installs them together as a single unit.

How many Claude Code plugins exist in 2026?

The official Anthropic marketplace lists 100+ reviewed plugins as of early 2026. Community directories track 4,200+ skills and 770+ MCP servers across the broader Claude Code extension ecosystem as of April 2026, per claudemarketplaces.com.

Do Claude Code plugins slow down sessions?

Yes — skill definitions and agent instructions load into the context window at session start. Installing plugins you use infrequently creates a permanent per-session cost. MCP server tool definitions benefit from lazy loading (MCP Tool Search reduces tool definition context use by up to 95%), but skill text loads eagerly. The practical rule: install plugins you use at least weekly; skip the rest.

What is the best Claude Code plugin for solo founders?

For founders managing both engineering and business operations, Soleur covers the most ground — 60+ agents across eight departments (engineering, marketing, legal, finance, operations, product, sales, support) with a cross-domain knowledge base that compounds with every task. For pure engineering workflows, context7 and code-review earn their install fastest.

Knowledge Compounding in AI Development: How Compound Engineering Beats Point Solutions

2026-04-23T00:00:00Z

Most AI tools are amnesiac. They begin each session with no memory of prior work, no knowledge of decisions made, no context accumulated from months of iteration. You prompt, they respond. The session ends. The next session begins from zero.

This is the architecture of a tool, not an organization. And for the founder trying to build at scale, it is the limiting factor that no prompt engineering, no model upgrade, and no additional tool subscription can solve.

Knowledge compounding is the architectural answer.

What Knowledge Compounding Is

Knowledge compounding in AI development is the systematic capture, organization, and reuse of decisions across every domain — so that each AI task starts from a more informed baseline than the last.

It is not a feature. It is an architecture decision: do the outputs of your AI sessions persist in a form that future sessions can read and build on, or do they disappear when the context window closes?

In a compound engineering system, they persist. The legal agent's contract position becomes a constraint the engineering agents reference before writing a feature. The brand guide the marketing agent updates gets read by every content-generation agent on every subsequent task. The competitive intelligence report from last quarter informs the product roadmap discussion today. The architectural decision recorded in a prior session becomes the reference point for the code review next month.

Every task teaches the system. Every session starts smarter than the last.

The Problem with Point Solutions

Point solutions plateau because they are stateless.

A stateless AI tool — even a highly capable one — runs each task without knowledge of prior context. The marketing agent doesn't know the legal agent determined that a particular claim creates regulatory exposure. The engineering agent doesn't know the product agent changed the spec. The financial model in the spreadsheet doesn't update when the sales pipeline shifts.

The founder ends up serving as the relay: reading the output of one tool, summarizing it, pasting it into the next tool, hoping nothing gets lost in translation. This is not delegation. It is manual coordination with extra steps.

As Soleur's analysis of why agentic tools plateau documented, the ceiling of point solutions is not the model's capability — it is the absence of an architecture that preserves and routes knowledge between tasks. The model could be more capable and the problem would remain. Statefulness is not a property of language models; it has to be built.

The Compound Engineering Lifecycle

Compound engineering is the practice of treating each development task as a step in a lifecycle that deposits knowledge, not just as a transaction that produces an output.

The lifecycle has five stages:

Brainstorm. Before building anything, explore the problem space with context. What has the company already decided about this domain? What constraints exist from legal, brand, and product strategy? The brainstorm stage is not open-ended ideation — it is ideation against the knowledge base.

Plan. Translate the brainstorm into a concrete implementation plan. The plan inherits the constraints surfaced in the brainstorm. Engineering plans reference security requirements. Marketing plans reference brand guidelines. Legal plans reference established positions. Cross-domain awareness before the first line of code is written.

Implement. Execute against the plan. Agents handle the execution; the founder provides judgment at decision gates. Nothing ships without review.

Review. Multi-perspective review before output is accepted. An engineering review catches security, performance, and quality issues. A legal review catches compliance exposure. A brand review catches voice inconsistencies. The review stage is where the cost of wrong is lowest — catching a problem in review is orders of magnitude cheaper than catching it in production.

Compound. The most important and most frequently skipped stage. After implementation, capture what was learned: what decisions were made, what constraints were discovered, what worked and what didn't. The compound stage is what makes the next task better than this one. Skip it, and the knowledge dies with the session.

What Gets Captured

The knowledge base in a compound engineering system is not a database. It is a collection of human-readable documents that agents can both read and write to:

Architecture decisions — why the system is structured the way it is, what alternatives were rejected, what constraints drove the choice
Legal positions — what the compliance requirements are, what claims the legal agent has approved, what data handling approaches have been cleared
Brand decisions — the brand guide, tone examples, visual identity, vocabulary do's and don'ts
Competitive intelligence — what competitors are doing, how the product is positioned relative to them, what claims are defensible
Product specifications — what is being built, what the acceptance criteria are, what the user is supposed to experience
Engineering learnings — what patterns have been established, what bugs have been fixed and why, what architectural choices have been made

Each of these is a domain of knowledge that a point solution would require the founder to carry manually. In a compound system, agents carry it.

Why Compounding Creates Structural Advantage

The compound effect is asymmetric. Two founders starting with the same AI capability but different architectures will diverge faster than linear.

The founder using stateless point solutions improves at the rate of their own learning. Each task is independent. Experience accumulates in the founder's head, not in the system.

The founder using a compound engineering architecture improves at the rate of organizational learning. Each task improves the system's knowledge of the company's constraints, decisions, and preferences. The fifth legal review is better than the first not because the model improved, but because the knowledge base contains the first four reviews' worth of company-specific context.

After 60 sessions, the gap is not marginal. The compound system has accumulated a knowledge base representing months of decision history. The stateless system's effective knowledge is exactly what the founder managed to paste into the context window for that session.

This is the structural advantage that compound knowledge creates: not faster individual tasks, but a system that builds organizational knowledge over time. The earlier you start building the knowledge layer, the deeper the advantage becomes before the market catches up.

Implementing Compound Engineering

The starting point is not a tool purchase. It is an architecture decision.

The question is: where does the output of your AI sessions go?

If the answer is "into the context window, then gone," the system is stateless. Every session starts from zero. The founder is the only persistent layer.

If the answer is "into a structured knowledge base that future agents can read," the system compounds. Each session builds on every prior session.

The knowledge base does not need to be complex. At Soleur, it is a collection of markdown files organized by domain and committed to the repository. Agents can read any file. Any agent can write a learning. The git history provides an audit trail. The result is an institutional memory that every agent in every domain can access — without the founder acting as the relay.

The discipline is consistency: after every significant task, run the compound step. Document the decisions made. Capture the constraints discovered. Record what worked. The compounding does not happen automatically — it happens because the lifecycle includes a mandatory stage at the end that makes it happen.

The Difference Between Learning and Compounding

There is a distinction worth making between individual task improvement and organizational compounding.

An AI model that gets feedback and improves its next response is learning at the task level. That is useful. It is not compound engineering.

Compound engineering is when the organizational knowledge — not just the model's capability — improves with each session. A better model with a stateless architecture still plateaus at coordination. A compound architecture with any sufficiently capable model builds leverage that grows over time.

The model is the executor. The knowledge base is the organization. The founder's judgment is the decision layer. These three layers interact to produce compound results. Optimizing only the model while ignoring the knowledge layer is the structural mistake that keeps most founders working harder rather than building leverage.

The one-person billion-dollar company becomes credible when this architecture is in place — not because the model is smarter, but because the organization it operates within remembers everything, connects everything, and improves with every session.

FAQ

What is knowledge compounding in AI?

Knowledge compounding in AI is the architectural practice of capturing the outputs, decisions, and learnings from AI sessions in a persistent knowledge base so that future sessions can read and build on them. It is the opposite of a stateless tool architecture, where each session begins fresh. With knowledge compounding, every task makes the system more capable — not because the model improves, but because the organization's accumulated knowledge grows.

What is compound engineering?

Compound engineering is a development practice that structures every task as a step in a knowledge-building lifecycle: brainstorm, plan, implement, review, and compound. The compound stage — capturing what was learned — is what makes each subsequent task better than the last. A compound engineering system accumulates architectural decisions, established patterns, and resolved edge cases in a readable knowledge base that agents reference on every future task.

How is knowledge compounding different from fine-tuning an AI model?

Fine-tuning modifies the model's weights to improve performance on a specific task distribution. Knowledge compounding does not modify the model at all — it builds an organizational knowledge layer alongside the model. Fine-tuning improves what the model knows at training time. Knowledge compounding improves what the organization knows in real time, with every task. These are complementary approaches; they address different layers of the system.

Can any AI tool support compound engineering, or is specialized tooling required?

The compound engineering lifecycle can be implemented with any AI tool capable of reading and writing files. The requirement is not a specific tool — it is a discipline of capturing outputs to a persistent knowledge base and a structured practice of reading that knowledge base at the start of each task. Specialized tooling like Soleur automates this lifecycle so the compound step happens as part of the workflow rather than as a manual afterthought. But the architecture decision — stateful vs. stateless — is independent of any specific tool.

What does a compound knowledge base actually look like?

In practice, a compound knowledge base is a set of structured documents organized by domain: engineering architecture decisions, legal positions, brand guidelines, competitive intelligence, product specifications. These documents are human-readable, human-editable, and accessible by AI agents. They live in the repository alongside the code, updated through a disciplined compound step at the end of each significant task. The knowledge base is not a database — it is institutional memory in document form.

Agents That Use APIs, Not Browsers (2026)

2026-04-23T00:00:00Z

Running a company alone means running a lot of vendor dashboards. Cloudflare, Stripe, Plausible, Resend, Hetzner — every one of them is a tab you keep open, a form you fill out, a setting you remember to flip. "Service automation" is the layer that lets an agent do that vendor work on your behalf, through the same APIs you would call by hand. Soleur's service automation shipped this week, and it is open source.

The bet underneath it: agents should talk to APIs, not browsers. We spent a month proving that out. Here is what we built, what we rejected, and what you can use today.

What service automation is, in one sentence

Service automation is the capability that lets an AI agent provision, configure, and operate third-party services — create a DNS record, issue a Stripe refund, spin up a Plausible site — by calling vendor APIs directly, using tokens you own, on your behalf.

That sentence matters because the phrase "service automation" is doing real work in the industry right now. Some tools mean "an agent that drives a browser through a dashboard." Others mean "a workflow engine that chains Zapier-style connectors." We mean neither. We mean an agent that reads a vendor's API contract, holds your token, makes the HTTP call, handles the error, and writes the result back into your knowledge base.

If you want the short version: your AI team gets credentials the same way a new hire does, and uses them the same way a senior engineer would — through the API, not the UI.

The fork in the road: browsers or APIs

Back in March we had a real decision to make. Service automation had been validated by founder interviews as one of the top-three requests. The open question was how an agent should actually carry out vendor work.

The popular answer in the agent industry is browser automation: run Playwright on a server, let the agent log into each dashboard, click through the forms, scrape the confirmation page. It looks great in demos. It is also how most "agent platforms" you see on launch day are actually built.

We rejected it. Four reasons, in the order they hurt:

Attack surface. Running a headless browser on your server that logs into external dashboards on behalf of your users removes nothing from the threat model — it adds to it. A server-side browser that follows redirects, loads arbitrary pages, and accepts scripted input is the canonical shape of a server-side-request-forgery primitive. Going API-first removes the server-side browser attack surface.
Cost. Our CFO flagged 2–4× infra-cost risk if we relied on browser automation. Headless browsers are RAM-hungry, they need long-lived sessions, and they fail in ways that require retries. A single REST call costs fractions of a cent. A browser session costs meaningful money.
Drift. Vendor dashboards change layout every few months. Vendor APIs change on deprecation schedules. If your automation tier is built on CSS selectors, every marketing redesign breaks your agent. If it is built on documented endpoints, you get years of stability.
Trust. When a founder hands an agent a credential, they want to know where it lives and what it does. "Our server never opens a browser to your dashboard" is a promise we can keep. "Our scraper won't do anything weird" is not.

So we went API-first and wrote the whole thing up in an architecture decision record. Three tiers, ordered by how much of the vendor universe they cover:

Tier 1 — Direct API + MCP. Target allocation: roughly 80% of services. Design, not measurement.
Tier 2 — Local browser automation. Target allocation: roughly 15%. This runs on the founder's own machine via our desktop app, not on our servers — different threat model entirely.
Tier 3 — Guided playbooks. Target allocation: roughly 5%. Deep-linked dashboard instructions with human review gates, for the last mile where no API exists.

Those percentages are design allocation, not measured. We are shipping the scaffolding this week; the real distribution will land over the next quarter as we grow coverage.

What shipped this week

The launch cut is honest about where we are. Three live API automations, two guided playbooks, fourteen BYOK providers wired into the credential layer.

Live automations (Tier 1):

Cloudflare MCP — DNS records, zone settings, page rules. Agents can configure a domain end-to-end.
Stripe MCP — customers, subscriptions, refunds, webhook endpoints. Your finance agent moves money with your token, not a stolen session.
Plausible API — create sites, read traffic, pull goal conversions. (Note: /api/v1/sites requires an Enterprise plan with a Sites API key — check your plan before wiring it up.)

Guided playbooks (Tier 3):

Hetzner — server provisioning, volume attach, firewall rules. Deep-linked into the Hetzner cloud console with a pre-filled config.
Resend — domain verification, API key issuance, send-test flow.

Credential layer (all tiers):

14 BYOK providers hooked into the credential store.
AES-256-GCM for data-at-rest, per-user HKDF-SHA256 key derivation. Your tokens, encrypted at rest, used by your agents. Each user's ciphertext is keyed to their own derived secret — a database leak does not yield usable credentials without the per-user material.

The PR was 1,685 lines across 15 files, added 20+ new tests, and shipped green against the existing suite. It is public, it is open source, and you can read every line.

Ready to try it?

Connect your repo at app.soleur.ai and let an agent provision your first service.

Why this matters if you are building alone

The hardest thing about being a solo founder is not the engineering. It is the other seventy percent — the vendor dashboards, the DNS flips at 11pm, the Stripe webhook you forgot to subscribe, the Plausible site you keep meaning to create for the new landing page.

Every one of those tasks is an API call. Every one of those API calls is something a well-briefed agent can handle, if — and only if — the agent has the credentials, the contract, and the authority.

Soleur's service automation gives the AI team all three. Credentials live in the encrypted BYOK layer. Contracts live in the MCP servers and playbook definitions. Authority lives in your repo — in the brand guide, the spec, the plan — where every agent reads from the same compounding knowledge base.

That last part is the lock-in break. An agent that can call Cloudflare for you is useful. An agent that can call Cloudflare for you and knows, from your brand guide, which domain owns which brand, and knows, from last week's learning file, that you always want Always Use HTTPS on — that is a teammate.

Why APIs compound and browsers do not

This is the same argument we made in why most agentic tools plateau, applied to a new surface.

A browser-based automation is a snowflake. Every site has its own DOM, its own auth flow, its own anti-bot heuristics. Every fix is a one-off. Nothing transfers.

An API-based automation is a contract. Once you have wrapped Stripe's API with agent-legible tools, the next agent that wants to issue a refund does not need to learn Stripe's dashboard — it needs to learn the contract, which is already documented, typed, and tested. The investment accrues.

That is what makes this release structurally different from the service-automation stories you see from browser-agent startups. We are not shipping a pile of scrapers. We are shipping a typed, tested, credentialed automation substrate that every agent in the organization can call the same way — from the marketing agent that wants to create a Plausible goal to the ops agent that wants to check a Hetzner firewall.

What it looks like from the founder's seat

The mental model we optimized for: the founder never touches a token file, never inspects a response header, never writes a retry loop. They say what they want in plain language. The AI team handles the rest.

A concrete example. You are launching a new landing page on a fresh subdomain. In a pre-automation world, that is a thirty-minute errand: open Cloudflare, add the CNAME, wait for propagation, open Plausible, create the site, copy the script tag, go back to the code, paste it, deploy, check analytics, realize the goal is not firing, go back to Plausible, create the goal. Eleven context switches.

In the post-automation world it is one sentence to your ops agent: "Spin up launch.soleur.ai, point it at the production app, and track signups as a conversion." The agent resolves the domain against your Cloudflare zone, creates the DNS record, waits for propagation, creates the Plausible site, records the site ID in your knowledge base, writes the goal configuration, and comes back with a verification checklist. You approve. It is done.

The time savings are real but secondary. The primary value is that the steps are now auditable and repeatable. Every decision the agent made is committed to your repo. The next time you launch a subdomain, the agent reads the prior run, applies the same configuration, and only stops to ask about the deltas. This is the compounding effect applied to vendor work — the same substrate that makes engineering work compound now applies to the rest of the company.

How this was built

For anyone interested in the architectural argument underneath the release: the full decision is written up as ADR-002 ("Three-Tier Service Automation") in the Soleur knowledge base. The short version is above. The long version walks through the CTO, CLO, and CFO objections to a server-side-browser design, the threat model we rejected, and the BYOK encryption scheme we adopted in its place. If you are building anything adjacent, it is worth reading as a template for "how to decide where agents get their hands dirty."

One rule we learned writing it: the moment you catch yourself saying "the agent will log in to the dashboard and…" — stop, and go find the API. In the rare case the vendor has no API, write a guided playbook and let the human keep the keys. Do not put a browser on your server.

What is next

Three live automations is a beachhead, not a platform. The roadmap from here:

Expand Tier 1 coverage: the shortlist is GitHub, Vercel, Supabase, and Mailchimp — all API-first, all natural fits for the MCP layer.
Ship the first Tier 2 integrations through the desktop app, for vendors whose highest-value workflows genuinely require a browser session (think "download this monthly CSV report" or "confirm a TOTP prompt").
Measure the actual tier distribution in production and report it. The 80/15/5 target needs real data behind it before we trust it.

If there is a vendor you want your AI team to handle, file it as an issue on the repo. We prioritize by founder pain, not vendor size.

Start here.

Connect your repo at app.soleur.ai and let an agent provision your first service.

The Billion-Dollar Solo Founder Stack (2026)

2026-04-22T00:00:00Z

What Is a Billion-Dollar Solo Founder?

A billion-dollar solo founder is one operator who runs a company generating a billion dollars in revenue by delegating every non-judgment function — engineering, marketing, legal, finance, operations, design, and customer service — to AI agents that share a compounding knowledge base. As Dario Amodei put it: "This is not a joke — you can have a one-person billion-dollar company within a year or two." The founder's role is no longer execution. It is decision-making, taste, and accountability — scaled by a stack that handles everything else.

The Medvi Proof Point

The prediction is no longer a prediction. It happened.

Matthew Gallagher launched Medvi from a Los Angeles apartment in September 2024 with $20,000 of his own money. The only other person on payroll is his younger brother Elliot. By the end of the first year, Medvi had posted $401 million in revenue across 250,000 customers at a 16.2% net profit margin. Year two is tracking toward $1.8 billion in sales.

Context sharpens the number. Hims & Hers, Medvi's largest competitor in the GLP-1 telehealth category, reported $2.4 billion of revenue with 2,442 employees and a 5.5% margin. Medvi is doing roughly three-quarters the revenue at triple the margin with one one-thousandth of the headcount. Nicholas Thompson, CEO of The Atlantic, put it bluntly on LinkedIn: "A man named Matt Gallagher appears to have created the first one-person billion-dollar-revenue AI company — selling GLP-1s."

The stack Gallagher used is not proprietary. Every tool is available to anyone reading this sentence. Per The Rundown AI and PYMNTS, the Medvi build uses ChatGPT, Claude, and Grok for code and copy, Midjourney and Runway for advertising creative, and ElevenLabs for voice-based customer service, with custom agents stitching the systems together. The regulated functions — physician oversight, prescriptions, pharmacy fulfillment — are outsourced to CareValidate and OpenLoop. Everything else runs through AI that Gallagher himself directs.

This is the shape of the proof. A commodity stack. A single operator. A business that clears nine-figure revenue in its first year and is on pace for ten figures in its second.

The Amodei Prediction, One Year Later

In May 2025, Dario Amodei predicted that a billion-dollar solopreneur would emerge in 2026. The canonical wording came during a press Q&A: "This is not a joke — you can have a one-person billion-dollar company within a year or two." When pressed, Amodei revised the probability to 70 to 80 percent.

Where he was wrong was the direction of his error. He underestimated the pace.

Amodei guessed the first solo unicorn would emerge in a market with minimal "human-institution-centric" dependencies — proprietary trading, or developer tooling. The actual breakout came in regulated healthcare, a vertical nobody would have listed on a whiteboard of low-coordination industries. The mechanism was the one Amodei described, but the vertical that proved it was the one he would have bet against. GLP-1 telehealth in 2024-2026 happened to have the right shape: massive demand, outsource-able clinical operations, and a greenfield where a digitally-native brand could grab shelf space before the incumbents finished their integrations.

The prediction is also not alone in the record. Sam Altman described an informal betting pool among tech executives for the first year it would happen. Benzinga and officechai both relayed the 70-80% figure alongside the prediction. What made Amodei's call specific was the timeline: within a year or two. We are now inside that window, and the first data point has arrived.

What Makes 2026 Different

The stack did not suddenly become possible. Three things converged.

Frontier-model multi-step reasoning. Through 2024, AI agents could execute one-shot tasks but failed at the second or third chained step. GPT-4 era models needed a human to close every loop. The 2025-2026 generation — Claude Opus 4.x, GPT-5, Gemini 2.x — reason across chained plans, recover from errors mid-chain, and hold state across long-horizon tasks. Anthropic's 2026 Agentic Coding Trends Report documents the trajectory: roughly 60% of surveyed engineering work already passes through AI, with multi-agent coordination now the headline trend rather than single-shot autocomplete. That shift — from one assisted step to many coordinated ones — is the difference between a coding assistant and an engineering agent.

Model Context Protocol (MCP). Agents that cannot reach your systems are toys. MCP, introduced by Anthropic in late 2024 and now standardized across the industry, gives agents a consistent way to talk to your tools — filesystem, database, Stripe, Cloudflare, GitHub, Supabase. This is the plumbing that turns a chat interface into an operator. Without MCP, Medvi's stack would need bespoke glue between every service. With it, a single agent can read a ticket, query the pharmacy partner's API, draft a response in ElevenLabs voice, and log the interaction — without a human pasting outputs between tabs.

Orchestration layers. Raw models plus raw MCP do not constitute an organization. The orchestration layer — Claude Code, Cursor, Soleur — packages the lifecycle: brainstorm, plan, implement, review, and compound. CIO's 2026 coverage of agentic workflows names orchestration as the decisive 2026 shift — not the models, but the systems that string them together. A solo founder does not need to know how a model routes between tools; the orchestration layer handles it and captures the state so the next session starts smarter than the last.

These three, together, are what separate 2026 from 2024. Strong reasoning plus universal tool access plus a lifecycle that compounds. Take any one away and the stack collapses back into point solutions.

The Stack by Function

A solo founder does not need eight tools. They need eight functions, each covered by either a specialist agent, a specialist tool, or a thin human layer where regulation requires one. Here is the functional stack that runs a 2026 company.

Engineering — Claude Code plus Soleur. Code is the most mature function. Claude Code handles the keystrokes — writing, reviewing, refactoring, running tests. Soleur handles the organization around the code — brainstorm, plan, review, compound — so the engineering agent reads the brand guide before touching copy and the legal agent flags compliance constraints before the schema change lands. Gallagher's website, checkout flow, and ad pages were built this way. One operator. Multiple coordinated agents. Zero engineers on the cap table.

Marketing — Soleur marketing agents. Eleven specialists covering brand, content, SEO, AEO, competitive intelligence, distribution, and campaign planning. The agents share a knowledge base, so the copywriter references the brand guide the brand architect wrote, the SEO agent aligns with the content calendar the campaign manager set, and every piece compounds on the last. This is the seam where point-tool stacks fail most visibly — marketing output without shared context reads like it was written by eleven unconnected freelancers, because functionally, it was.

Legal — Soleur legal agents plus licensed human counsel for jurisdictional matters. Agents draft terms of service, privacy policies, standard vendor agreements, and compliance audits against GDPR, CCPA, and HIPAA. They flag what a contract says and what a regulation requires. They do not replace licensed counsel for anything that crosses a jurisdiction you have not yet cleared, and they do not file on your behalf. The pattern is straightforward: agents produce a defensible draft; a licensed attorney reviews and signs off on anything that carries real liability. This section is not legal advice and is not a substitute for licensed counsel.

Finance — Soleur finance agents plus a CPA for filings. Budgeting, revenue forecasting, unit economics, burn analysis, investor updates, and month-end close happen in agents. The knowledge base carries the chart of accounts, the pricing history, and the cash position across sessions. For tax filings, regulatory returns, and audited financials, a licensed CPA signs. The agent does the 90% that a bookkeeper and an FP&A analyst used to split; the CPA does the 10% that requires a license and a stamp. This section is not tax or accounting advice and is not a substitute for a licensed CPA.

Operations — Zapier or Make. The connective tissue. When a customer signs up, the ops layer routes the event to the pharmacy partner, notifies the support agent, updates the CRM, and books the revenue. Zapier and Make remain the cleanest substrates for this because they are deterministic — you want your payment pipeline to behave identically on the ten-thousandth run as on the first. Let agents design the workflows; let automation platforms execute them.

Design — Midjourney, Figma, or Canva. Brand identity, ad creative, product UI. Midjourney and Runway generate the raw imagery. Figma or Canva assembles it into the artifacts that actually ship — the landing page, the ad set, the pitch deck. Gallagher used Midjourney and Runway to produce every piece of ad creative Medvi ran. The bottleneck for most solo founders is not pixel production; it is taste. Volume is free. Taste is the operator's job.

Customer Service — Custom agents plus ElevenLabs. This is where Gallagher's stack gets specific. Per PYMNTS, Medvi runs customer inquiries through custom AI agents backed by ElevenLabs voice, with human escalation only for clinical questions the agent is instructed to route to the outsourced physician network. The stack handles intent recognition, policy application, refund logic, and status checks at volume. A founder who built this right is awake when every customer is, in every timezone, in a voice indistinguishable from a call-center agent — at a cost per interaction approaching zero.

What Still Requires the Human

This is where the trust scaffolding lives. The stack is powerful. It is not autonomous.

Taste. An agent can generate a hundred hero visuals. It cannot tell you which one reads as your brand. An agent can draft ten positioning statements. It cannot tell you which one will land with a founder on Hacker News at 2 AM. Taste — the aesthetic, editorial, and strategic judgment that separates a brand from a content farm — is the part that does not yet transfer. The founders who win in 2026 are not the ones with the most compute. They are the ones whose taste is good enough that the compute amplifies the right thing.

Positioning. Where you choose to compete is the single highest-leverage decision a company ever makes, and it is not a decision a model can make for you. The model can research the market, map the competitive landscape, and generate a dozen candidate wedges. The operator is the one who looks at the list and says "we go here, not there" — and then holds that line for eighteen months when the agent would happily pivot to the shinier adjacent wedge every week.

Final go/no-go. Launching a product, shipping a feature, firing a vendor, signing a contract above a threshold. Every billion-dollar company has a handful of moments where one decision is load-bearing for the next five years. The agent's job is to surface the decision cleanly with the evidence attached. The founder's job is to make the call. Any stack that hides this boundary is a stack that will blow up spectacularly the first time a plausible-sounding hallucination crosses a compliance line.

Regulated actions. Tax filings signed by a CPA. Litigation led by a licensed attorney. M&A closed by a banker. Jurisdictional legal advice delivered by someone barred in that jurisdiction. Clinical prescriptions written by a licensed physician. These exist at the intersection of liability and license, and the license belongs to a human. The pattern is not to replace them. It is to compress them — the CPA handles the filing, the agent handles the other 359 days of the year of bookkeeping that leads to the filing.

The founder's job has not disappeared. It has concentrated. Execution is delegated. Judgment is not.

How Soleur Fits

The stack described above is assemble-it-yourself. Claude Code, Zapier, Midjourney, ElevenLabs — every piece is a separate tool, every piece is a separate login, every piece is a separate context window. Gallagher assembled his. Most founders will not.

Soleur is the Company-as-a-Service platform that ships the organization prewired. 60+ agents across engineering, marketing, legal, finance, operations, product, sales, and support. 60+ skills covering the lifecycle: brainstorm, plan, implement, review, compound. One shared knowledge base where every decision the founder makes teaches the system. Every feature gets better and faster than the last, because the next session starts from a more informed baseline than the previous one.

The companion argument for this — why the one-person billion-dollar company is an engineering problem rather than a business one — is the engineering-problem companion to this post. That piece covers the structural reason the math works: coordination costs dropping to near zero when knowledge compounds across domains. This piece covers the stack that makes it operational. Company-as-a-Service is the organizing concept that ties both together.

Pricing and access: see the Soleur pricing page. The window described in the companion post — the time before every company has this capability — is what the stack is for.

Counterpoint: What Could Go Wrong

A trust-scaffolded piece owes the reader an honest account of the failure modes. Here are the four that matter most, ordered by likelihood.

Regulatory and compliance blowback. Medvi itself is not a clean proof point. Commenters on Thompson's LinkedIn post raised FDA concerns and questions about AI-generated endorsement imagery. A solo operator moving at agent speed can cross a regulatory line before a human compliance officer would have reviewed the creative. The failure modes are specific and common: misclassifying a 1099 contractor as a 1099 when the facts make them a W-2, running ads with synthetic celebrity likenesses that trigger right-of-publicity claims, collecting EU consent with a banner that a GDPR regulator reads as non-compliant, making tax-withholding errors on multi-state payroll, and filing late or underpaying an estimated tax obligation because the agent's calendar drifted. Agents do not carry license risk. Founders do. The mitigation is not to slow down; it is to put the licensed human — CPA, attorney, compliance officer — on the high-stakes gates and let the agent run everything in between.

Model and API costs at real scale. A Claude or GPT API bill that is $50 per month at prototype scale becomes $5,000-50,000 per month when the same agent is handling production customer service, code review, and content generation across a business doing eight figures of revenue. The economics still work — Medvi's 16.2% margin on $401M dwarfs what a traditional org would achieve at the same revenue — but the bill is real, and a founder who models it as negligible will be surprised. Plan the variable cost per interaction the same way you plan the variable cost of a customer acquisition: as a line item, with sensitivity to model price changes that happen on the model provider's timeline, not yours.

Attention-economy collapse. AI creative is cheap, so every founder is producing more of it, so the supply of content is exploding, so the price of attention keeps climbing. In 2023 a $5 CPM was an expensive channel. By 2026 the same channel is $25 and the creative needs to be ten times better to achieve the same click-through. A stack that generates a thousand ad variants does not guarantee one of them works. The counterfactual a founder has to hold is: if every competitor has the same stack, the differentiator is not the stack — it is the taste, the brand, and the distribution advantage. A founder who treats AI as the moat will wake up in 18 months and discover that it was table stakes.

Vibe-coded technical debt. An agent can ship a feature in an afternoon. The feature has tests that pass and behavior that looks correct. It also has implicit assumptions, undocumented invariants, and edge cases the agent never considered because the founder never asked. Twelve months in, the codebase is 200,000 lines of mostly-working software that nobody — not the founder, not the agents — fully understands. The fix is not "stop using agents." It is to insist on review gates, test coverage, and architecture decisions that survive the handoff between sessions. The orchestration layer is where this happens or fails to happen. Without it, the stack is velocity with no coherence.

None of these are hypothetical. All four are showing up in solo-founder post-mortems as of this writing. The stack works. It also carries a specific risk profile, and founders who pretend otherwise will learn it on their own timeline.

FAQ

Who has already built a one-person billion-dollar company?

Matthew Gallagher's Medvi is the first documented case. Launched in September 2024 from a Los Angeles apartment with $20,000, the company posted $401 million of revenue in its first full year and is tracking to $1.8 billion in year two, per The Rundown AI. The only other full-time employee is Gallagher's brother Elliot. Regulated clinical functions are outsourced to CareValidate and OpenLoop; everything else runs on an AI stack of ChatGPT, Claude, Grok, Midjourney, Runway, and ElevenLabs. The proof point is narrow — one company in one vertical — but it is real, and it landed inside the window Amodei predicted.

Is this ethical?

The honest answer is: it depends on the company. A solo founder running a compounding AI organization is not inherently unethical. Compressing eight corporate functions into one operator is a productivity story, not a moral failing. The ethical questions sharpen where the stack crosses a regulated domain or where AI output is presented as human work without disclosure. Medvi has drawn fair scrutiny about FDA compliance and synthetic endorsement imagery. Those are real issues, and they are not inherent to the solo model — they are specific choices. A founder who runs the same stack with transparent AI disclosure, clean regulatory alignment, and honest marketing is doing something that was not previously possible, not something previously forbidden.

Do you still hire anyone?

Yes, selectively. Gallagher's stack includes his brother as a co-operator and contract engineers and account managers as variable-cost specialists. The pattern is a vanishing full-time headcount and a rising contract layer that flexes to demand. Hire where licensed expertise is non-delegable (CPA, attorney, clinical supervisor) and where judgment needs a second brain (a co-founder, a senior specialist for a specific campaign). Do not hire to do what an agent already does well — copywriting at volume, code at the line level, first-draft ad creative, tier-one support. Headcount, in the 2026 model, is a scalpel, not a hammer.

What does the Claude API cost look like at scale?

The order of magnitude matters more than the exact number. A founder building a prototype pays low three figures a month in API spend. A founder running production customer service, code review, and content at the scale of a low-eight-figure revenue business pays low-to-mid five figures. At Medvi's revenue scale ($401M year one, $1.8B projected year two), the AI stack cost is non-trivial — likely low six figures per month across all providers — but it is a rounding error against the revenue it enables. The discipline is to track cost per meaningful interaction (cost per resolved ticket, cost per generated ad variant, cost per shipped PR) the same way you track cost per acquired customer. Model prices will shift; your unit economics need to survive that.

Which model should a solo founder standardize on?

There is no single right answer, and a founder who locks in on one is taking avoidable concentration risk. The pragmatic 2026 pattern is Claude Opus 4.x for agentic engineering and long-horizon reasoning, GPT-5 for broad consumer-facing content, and Gemini 2.x for cost-sensitive bulk generation — with the orchestration layer abstracting the choice. Soleur is built around Claude Code and the Anthropic model line because it is the current state of the art for agentic software work, but the knowledge base is provider-agnostic and migrating to a different model family does not require rebuilding the organization. Pick the best current model; keep the orchestration layer portable.

Is a one-person company actually defensible against a 20-person team?

In the short run, yes — if the stack compounds. The solo founder's knowledge base is continuously consolidating context across domains. A traditional team of 20 is distributing that context across Slack threads, Notion pages, and the heads of people who leave. Over 24 months, the gap widens. That said, "defensible" has limits: a team of 20 with the same stack and better taste will outperform a solo operator with the same stack and worse taste. The defensibility is not in the headcount delta. It is in the compounding of decisions. This is the argument the companion post makes at length.

What functions are hardest to delegate to agents?

Anything where the right answer depends on taste the founder has not yet taught the system. Brand positioning at first-contact quality. Sales conversations where a deal hinges on reading the room. Hiring conversations. High-stakes regulatory filings. The pattern: the earlier in the company's life, the more concentrated taste-dependent work is in the founder. As the knowledge base thickens, more of it transfers — but the transfer requires the founder to explicitly teach, not just delegate. Founders who assume agents will reverse-engineer their taste from output alone will find the output has their brand and none of their judgment.

How does a non-technical founder build this stack?

The same way Gallagher did. He is not known as a career engineer. He used ChatGPT, Claude, and Grok to write the code, Midjourney and Runway to produce the creative, and ElevenLabs plus custom agents for customer service. The technical bar for operating this stack in 2026 is meaningfully lower than it was in 2024. What a non-technical founder needs is the orchestration layer — Soleur, Cursor, Claude Code — that packages the lifecycle so the founder does not have to learn the tooling to run the company. The founder still makes decisions about what to build, who to sell it to, and when to ship. The stack handles the keystrokes.

Is the window closing or opening?

Both. It is opening because the tools keep getting cheaper, more capable, and more accessible — what was an engineering feat in 2024 is a weekend build in 2026. It is closing because every new entrant competes on the same stack, so the differentiator reverts to taste, distribution, and compounding knowledge. The solo founder who starts their compounding lifecycle today has twelve to twenty-four months of structural advantage over a founder who starts in 2027 — the knowledge base they build in that window cannot be replicated by a well-funded latecomer on day one. The stack is democratized. The compound is not.

What would have to be true for this to fail?

Three conditions would close the opportunity. First, a regulatory response that specifically targets AI-operated businesses — mandatory disclosure of AI use in customer interactions, liability frameworks that make the founder personally responsible for agent outputs, or licensing regimes for AI-assisted professional services. Second, a model-pricing reversion that makes the API layer 10x more expensive, which would not kill the model but would collapse the margin advantage solo operators enjoy today. Third, a loss of consumer trust in AI-generated content broad enough to make the cost of a brand built on AI creative higher than the cost of a brand built on human creative. Any one of these is plausible. All three together would end the window. None are currently in motion at scale, but a founder betting the company on this stack should watch all three and have a plan for each.

Start Building

The stack is commodity. The compounding organization is not. Start your lifecycle at Soleur pricing or join the waitlist to build the billion-dollar company before the compounding window closes.

Soleur vs. Devin: AI Software Engineer vs. AI Organization

2026-04-21T00:00:00Z

Devin is the price anchor for autonomous AI agents. Cognition Labs' AI software engineer handles long-horizon coding tasks -- writing code, running tests, fixing bugs, browsing documentation, and deploying software -- with a degree of autonomy that made it the reference point for what "AI doing real engineering work" means. At $20/month, it is accessible to every solo founder who codes.

The question is not whether Devin is impressive. It is whether an AI software engineer is what a solo founder actually needs.

Devin and Soleur both automate work that used to require human expertise and both fit into Claude Code-native workflows. But their scope reflects fundamentally different answers to one question: what problem is the solo founder actually trying to solve?

What Devin Actually Is

Devin is Cognition Labs' autonomous AI software engineer. It is designed for long-horizon software engineering tasks: given a problem statement or GitHub issue, Devin plans a solution, writes code, runs tests, debugs failures, reads documentation, and submits a pull request. It has its own browser, terminal, and code editor -- it operates as an autonomous engineer in a sandboxed environment.

Devin is purpose-built for software engineering and nothing else. It does not draft legal contracts, run competitive intelligence scans, build financial models, or plan marketing campaigns. It is an extraordinarily capable engineering resource constrained to engineering problems.

That constraint is deliberate. Cognition built Devin to do one job exceptionally well: write and ship production-quality software without hand-holding.

What Soleur Actually Is

Soleur is the Company-as-a-Service platform. 66 agents, 73 skills, and a compounding knowledge base organized across 8 business departments -- engineering, marketing, legal, finance, operations, product, sales, support, and community.

The engineering department contains what Devin provides in isolation: architecture design, code review, infrastructure provisioning, deployment, and security analysis. Soleur's engineering agents run inside the same Claude Code environment as the founder. They plan, implement, review, and ship alongside a legal agent that generates contracts, a marketing agent that writes copy and runs competitive analysis, a finance agent that models revenue, and a product agent that validates specs before engineering starts building them.

The compounding knowledge base is the structural difference. When Soleur's product agent completes a competitive analysis, the marketing agents read it. When the legal agent documents a compliance requirement, the engineering agents reference it before building the relevant feature. When the brand-architect agent writes the brand guide, every piece of copy the marketing agents generate afterward reflects it. Knowledge does not live in silos -- it accumulates across domains and every decision becomes institutional memory.

The Core Distinction: One Department vs. Nine

Devin solves the engineering hiring problem. A solo founder who needs engineering output -- and does not want to hire engineers -- has a credible option at $20/month. For companies that are genuinely engineering-only problems, this is the right calculation.

The problem most solo founders face is not that they need to write more code. It is that they are simultaneously the CEO, CTO, CMO, CLO, CFO, COO, CPO, and VP of Sales. Devin cannot write the privacy policy that the engineering agent needs to reference. It cannot run the competitive analysis that should precede the product roadmap. It cannot draft the fundraising summary that follows the financial model. And it cannot remember that the legal agent determined last month that a particular data-handling approach creates regulatory exposure -- because Devin has no cross-domain knowledge base.

Building a billion-dollar company requires solving all nine problems, not optimizing one of them.

Where They Differ

Scope

Devin: software engineering, exclusively.

Soleur: 8 departments. Engineering is one of nine. The marketing, legal, finance, operations, product, sales, support, and community domains receive the same depth of specialist coverage as engineering.

The three domains that carry the highest downside risk for a solo founder -- legal, finance, and product strategy -- are absent from Devin's scope entirely. A missed compliance requirement, a flawed financial model, or a product roadmap that ignores competitive dynamics can make the engineering investment worthless.

Autonomy Model

Devin operates as an autonomous engineer. It receives a task and executes it independently, surfacing results when complete. The founder reviews the output, not the process.

Soleur's lifecycle -- brainstorm → plan → implement → review → compound -- is structured around decision gates, not autonomous cycles. The plan is visible before implementation starts. The review happens before anything ships. The founder provides judgment at every gate; agents handle execution. This is not a constraint -- it is an architecture designed for decisions where the cost of wrong is high.

Knowledge Persistence

Devin's context window ends at the session. It does not accumulate institutional memory about your company, your codebase's architectural decisions, or the reasoning behind past technical choices. Each new task starts from the current state of the repository, not from a compounding body of organizational knowledge.

Soleur's compound step captures what was decided and why at the end of every session. Engineering decisions become architectural learnings. Legal edge cases become compliance guardrails. Competitive intelligence updates become product strategy inputs. The knowledge base is a git-tracked directory of Markdown files -- readable, auditable, and editable by the founder directly -- that compounds with every session across every domain.

The first time Soleur's engineering agents tackle a problem, they work from what exists. The twentieth time, they reference 19 sessions of architectural context, past decisions, and established patterns. The engineering gets better. So does everything else.

Pricing

Devin: $20/month subscription.

Soleur: open-source, free platform. Your costs are the Claude API credits the agents consume.

The pricing comparison is less straightforward than the headline numbers suggest. Devin at $20/month is a subscription for engineering output. Soleur's costs scale with usage -- a company running extensive agent sessions will spend more on Claude API than $20/month. The open-source model is lower cost for founders starting out; the total cost of Soleur depends on session volume at scale.

The more material pricing consideration: Devin covers one of nine departments a solo founder needs to run. Replacing all nine with separate specialized tools -- an AI coding agent, an AI legal tool, an AI finance tool, an AI marketing tool -- costs orders of magnitude more and produces no cross-domain coherence. Soleur covers all nine in a single platform.

How Each Fits Into the Workflow

A solo founder using Devin writes a spec, hands it to Devin, and reviews the pull request. Devin handles the coding work between spec and PR.

A solo founder using Soleur starts a session: brainstorm the spec with the product agent, plan the implementation with the engineering architect, implement with the engineering agents, review with the code review agents, ship with the workflow agents, and capture learnings with the compound step. Parallel to engineering, the marketing agents are running a content calendar, the legal agents are reviewing the new feature for compliance, and the finance agents are updating the revenue model based on the new feature's expected impact.

The engineering output from Soleur's agents is comparable in quality to what Devin delivers on well-specified tasks. The difference is what surrounds the engineering output: the product strategy that preceded it, the legal review that runs alongside it, the marketing content that ships with it, and the institutional memory that captures it afterward.

The $20/Month Framing Problem

Devin at $20/month is often framed as the baseline cost for "AI that does real work." This framing obscures what Devin actually replaces: one engineer working on one category of problem.

Running a company requires nine categories. At $20/month for the engineering layer, the question becomes: what do the other eight cost? If the answer is "the founder's time," the $20/month number dramatically understates the real cost of the current stack.

The relevant comparison is not Devin at $20/month versus Soleur at $0/month. It is whether an engineering-only tool solves the problem the founder actually has.

When Devin Is the Right Choice

Devin is the right choice for founders whose bottleneck is engineering velocity. If you have a validated product, a clear roadmap, legal and financial infrastructure already in place, and the remaining constraint is writing and shipping code faster, Devin's autonomous engineering capability at $20/month is a strong option.

It is also the right choice if your company is a pure software engineering problem with no meaningful marketing, legal, or financial complexity. Some companies genuinely are -- developer tools, infrastructure products, and technical SaaS built by a single founder for a technical audience can run with minimal non-engineering overhead for extended periods.

When Soleur Is the Right Choice

Soleur is the right choice when the bottleneck is not just engineering velocity. When the missing piece is legal strategy that informs engineering decisions, a financial model that shapes the product roadmap, or marketing that reflects competitive positioning -- not just code that ships faster -- an engineering-only tool addresses the wrong problem.

Solo founders building companies where brand precision, legal compliance, financial planning, and product strategy are differentiators cannot route all complexity through an engineering tool. The first billion-dollar solo company will not be built by accelerating engineering in isolation. It will be built by a founder whose judgment is amplified across every domain -- where every decision builds institutional memory, and every new session benefits from everything the company has learned.

If the company you are building requires more than engineering, Soleur covers the full stack. Devin does not.

What you need	Devin	Soleur
Autonomous software engineering	Yes	Yes
Long-horizon coding tasks	Yes	Yes
Sandboxed browser and terminal access	Yes	Partial
Pre-built domain agents (legal, marketing, finance)	No	Yes
Cross-domain compounding knowledge base	No	Yes
Workflow lifecycle (brainstorm through ship)	No	Yes
Human-in-the-loop decision gates	No	Yes
Open-source and local-first	No	Yes
Pricing	$20/month	Free (API costs)

FAQ

Q: Can Devin and Soleur be used together?

Yes. Devin and Soleur are not mutually exclusive. A founder could use Soleur for the full organizational workflow -- planning, product strategy, legal, finance, marketing -- while delegating specific long-horizon coding tasks to Devin as the execution layer for well-scoped engineering problems. Soleur's compound step would capture the architectural decisions Devin's implementation surfaces, feeding them back into the organization's knowledge base.

Q: Devin is described as an AI software engineer. Is it comparable to Soleur's engineering agents?

For pure coding velocity on well-specified tasks, Devin is purpose-built for autonomous execution of long-horizon engineering work. Soleur's engineering agents operate as part of a larger organizational workflow with access to cross-domain context -- product specs, legal requirements, brand guidelines -- that Devin's isolated engineering context does not include. Which is better depends on whether the engineering work benefits from that cross-domain organizational context.

Q: Why does Soleur cover eight domains? Isn't most of what a technical solo founder needs engineering?

Engineering is the most visible 30% of running a company. The other 70% -- legal compliance, financial planning, marketing, customer support, product strategy, sales, and operations -- determines whether the engineering investment produces a company. Technical founders underweight non-engineering domains because those are the domains they are least comfortable with. Soleur covers all eight precisely because the painful constraints for most technical solo founders live outside engineering, not inside it.

Q: What is the "autonomous coding comparison" between Devin and Soleur?

Devin specializes in autonomous execution of coding tasks in a sandboxed environment with browser, terminal, and editor access -- receive a task, produce a pull request. Soleur's engineering agents run in the founder's actual development environment with access to the full organizational knowledge base: they plan before implementing and review before shipping, integrating engineering decisions with broader company context. Devin optimizes for engineering throughput on isolated tasks; Soleur optimizes for organizational coherence across all eight domains.

The One-Person Billion-Dollar Company: Why It's an Engineering Problem

2026-04-21T00:00:00Z

The first billion-dollar company run by one person is not a thought experiment. It is a prediction with a timeline.

This post is part of the Billion-Dollar Solo Founder Stack series — the pillar covers the full stack by function, the Medvi proof, and what still requires the human. This companion piece argues for the engineering-problem framing.

Dario Amodei, CEO of Anthropic, predicted that a one-person billion-dollar company would emerge as soon as 2026. Sam Altman described an informal betting pool among tech executives for "the first year that there is a one-person billion-dollar company." TechCrunch reported on the mechanism: AI agents extending beyond engineering into every function a company needs.

These are not idle predictions. They describe a structural shift in what it costs to run a company.

Why a Billion-Dollar Company Historically Required Hundreds of People

The reason billion-dollar companies required large headcounts was not ambition. It was coordination.

Building at scale requires eight distinct functions: engineering, marketing, legal, finance, operations, product, sales, and support. Each requires domain expertise. Each generates decisions. And every decision in one domain constrains every other domain — the legal strategy limits marketing campaigns, the financial model drives the product roadmap, the engineering architecture defines operational complexity.

For most of the history of business, the only way to hold all that context in one place was to have people who talked to each other. An organization was, at its core, a coordination system. The more functions you needed, the more people you hired. The headcount scaled with the company's surface area.

AI tools compressed the individual task. A coding assistant writes code faster. A contract template saves legal fees. A copywriting tool drafts faster. But these are speed improvements on isolated tasks. They do not solve the coordination problem. The decision the legal tool produced still does not reach the marketing tool. The insight the engineering agent generated still disappears when the session ends.

Point solutions made solo founders faster. They did not make them organizations.

What Changes the Math

The bet on the one-person billion-dollar company is not a bet on better tools. It is a bet on a different architecture.

The architecture is compound knowledge: a knowledge base that captures every decision across every domain and routes it to every agent that needs it. Marketing agents read what legal decided. Engineering agents reference what product specified. Finance agents update the model when sales closes a deal. No founder relay required.

When knowledge compounds, two things change.

First, coordination costs drop to near zero. The founder's job shifts from manually carrying context between domains to making decisions within a system that already knows the context. This is the function headcount has always performed — holding organizational memory — done by the knowledge base instead.

Second, every task makes the system more capable. The first time the legal agent drafts a contract, it works from general principles. The twentieth time, it works from 19 sessions of company-specific requirements, established positions, and accumulated edge cases. The marketing agents that have observed 12 months of brand guide evolution write with a precision that no fresh context window can match.

The compound effect means the one-person company does not plateau where point solutions do. It scales.

The Organizational Model

Company-as-a-Service is the structure that makes this concrete. Not a set of AI tools, but a full AI organization: specialist agents for each domain, coordinated by a shared knowledge base, operated by one founder who makes decisions and delegates execution.

Kuo Zhang, President of Alibaba.com, wrote in Fortune that agentic AI is dismantling the "Execution Wall" that previously separated solo entrepreneurs from large corporations — absorbing administrative complexity, compressing supplier negotiations and logistics coordination, and shifting competitive advantage from resources and headcount to judgment, taste, and strategic vision. The constraint was never the founder's capability. It was the cost of coordination at the boundaries between functions.

Remove the coordination cost. Keep the founder's judgment. The result is a company that behaves like an organization of hundreds — because every domain has specialist coverage, every decision is captured, and every subsequent session starts from a more informed baseline.

In practice, this means:

An engineering agent that reviews pull requests against legal constraints, brand guidelines, and product specifications — simultaneously, without the founder acting as relay
A marketing agent that reflects the latest competitive intelligence and brand strategy when drafting copy, because both live in the same knowledge base
A financial model that updates when the sales pipeline moves, the engineering velocity changes, or the product roadmap shifts
A legal agent that flags when a new product feature touches a compliance requirement documented in a prior session

Each of these is a solo founder operating at team scale — not because they are working faster, but because the system they are working within holds the coordination that used to require a team.

The Leverage Inflection Point

There is a phase change between "AI making a solo founder faster" and "AI enabling a solo founder to run a company."

The phase change happens at compound knowledge. Before it, the founder is still the relay. After it, the system carries the context and the founder carries the judgment.

The supply side of this shift is visible in the data: solo-founded startups have risen from 23.7% to 36.3% of all new ventures between 2019 and the first half of 2025, according to Carta's Solo Founders Report — the first time solo founding has reached this scale in over 50 years of startup formation. The infrastructure enabling this shift is not just productivity tools. It is the emergence of systems that can hold organizational memory across domains.

The founders who reach billion-dollar scale from a single person will not be the ones with the best prompts. They will be the ones whose organizations remember the most, connect the most, and improve the most reliably between sessions.

The first hundred sessions are learning the company. The next hundred sessions are operating the company. The third hundred sessions are scaling the company. The founder's input is required at each stage — but what that input is changes as the knowledge base deepens.

What It Requires

The one-person billion-dollar company is not automatic. It requires three things from the founder:

A commitment to building the knowledge layer. The system cannot compound knowledge that was never captured. Every architectural decision, brand choice, legal position, and pricing model that lives only in the founder's head is a coordination bottleneck waiting to be a crisis. The discipline of capturing decisions — in the format agents can read and build on — is the foundation everything else rests on.

A lifecycle, not a prompt. The founders who plateau at point solutions are using AI transactionally: here is a task, here is a response, done. The founders who build compound organizations treat each task as a step in a lifecycle — brainstorm, plan, implement, review, and compound. The compound step is not optional. It is what makes the next session better than this one.

Judgment at every gate. The system executes. The founder decides. This is the design. Human-in-the-loop decision gates are not a concession to AI limitations — they are the architecture that lets a single person exercise judgment across all nine domains without being overwhelmed by execution. The founder who stays in the judgment role rather than the execution role is the founder who can actually manage a nine-department organization alone.

The Competitive Window

The one-person billion-dollar company is not a permanent opportunity. It is a window.

The companies that build compound AI organizations in the next two to three years will operate with structural advantages that cannot be closed by adding headcount. Their knowledge bases will be deeper, their agents more specialized, and their compounding cycles will have had more time to run. A well-funded team of 50 hired in 2028 will not quickly replicate the institutional memory an AI organization built over three years of compounding decisions.

The window is the time before every company has this capability. Today, most companies are still using point solutions. The coordination cost is still a moat — but in reverse. The founders who close the coordination gap first do not just compete with traditional companies. They compete differently. And the gap compounds.

Getting Started

The path to a compound AI organization begins with one decision: what does your knowledge layer contain today?

For most solo founders, the answer is: less than you think. Brand decisions exist in your head. Legal positions were resolved and forgotten. Engineering choices were made without documentation. The first work of building a compound organization is excavation — surfacing what the company already knows and putting it in a form agents can read.

Then the lifecycle begins: brainstorm with context, plan with constraints, implement with review, compound with every session. Not faster individual tasks. A better organization every month.

The first billion-dollar company built by one person will not be built by working harder. It will be built by an organization that compounds — and the founder who built it started before the window closed.

Start building →

FAQ

Is a one-person billion-dollar company actually possible?

The prediction comes from credible sources at the highest levels of the AI industry. Dario Amodei predicted it would emerge as soon as 2026. Sam Altman described an informal executive betting pool for the first year it happens. Kuo Zhang of Alibaba.com wrote that agentic AI is dismantling the Execution Wall that historically required large teams. The mechanism is structural, not motivational: compounding AI organizations that hold cross-domain context eliminate the coordination cost that previously required hundreds of people.

What is compound knowledge and why does it matter?

Compound knowledge is what happens when every AI task generates a learning that routes back into the system. Legal decisions become constraints the engineering agents reference. Brand choices become rules the marketing agents follow. Each session starts from a more informed baseline than the last. The result is an organization that improves structurally with every task, not just an individual who works faster. Without compound knowledge, AI tools plateau at the level of faster individual work. With it, they scale to the level of a coordinated organization.

How is this different from using a collection of AI tools?

Point solutions are stateless. They begin fresh with each session, in each domain, without knowledge of what other tools decided. A collection of AI tools does not produce cross-domain coordination. A compound AI organization does. The legal agent knows what the marketing agent published. The engineering agent knows what the product agent specified. When that coordination happens in the knowledge base rather than the founder's head, the founder can operate at organizational scale.

How long does it take to build a compound AI organization?

The first sessions establish the knowledge layer — capturing existing decisions, constraints, and context. The compounding begins immediately: each session generates learnings that improve the next. The practical horizon is 60-90 days to a functional multi-domain organization, and 6-12 months to a deeply compounded one where the system's accumulated knowledge represents a meaningful structural advantage. The earlier you start, the deeper the advantage before the window closes.

What does the founder actually do in a one-person company run by AI?

The founder makes decisions and the system executes them. Every domain has a lifecycle: brainstorm, plan, implement, review, compound. The founder provides judgment at each gate — defining objectives, approving plans, reviewing outputs, resolving tradeoffs. The agents handle research, drafting, implementation, and review. This is not passive ownership. It is active decision-making across nine domains without execution overhead. The skill that matters most is the quality of the decisions, not the speed of execution.

Soleur vs. Paperclip: Domain Intelligence vs. AI Company Orchestration

2026-03-31T00:00:00Z

Paperclip reached 14,600+ GitHub stars with a straightforward premise: give AI agents an org chart, a budget, a schedule, and governance controls, and they can run a company without humans. Zero-human company orchestration, MIT-licensed, self-hosted. The traction is real. The category framing is direct.

Soleur and Paperclip both target the same destination -- a company that operates with minimal human overhead -- but they approach it from opposite ends of the stack.

Paperclip is infrastructure. It tells agents when to run, how much to spend, who reports to whom, and what to do when something goes wrong. It does not tell agents what to know, how to reason about legal risk, or what makes a good marketing strategy. You bring your own agents and domain logic.

Soleur is intelligence. 66 agents, 73 skills, and a compounding knowledge base across 8 departments -- engineering, marketing, legal, finance, operations, product, sales, and support. Every agent carries domain knowledge. Every session makes the system smarter. The orchestration is the workflow lifecycle: brainstorm → plan → implement → review → compound.

Neither platform is complete without what the other provides. Understanding what each actually solves is the first step to knowing which one belongs in your stack -- or whether you need both.

What Paperclip Actually Is

Paperclip is an open-source orchestration platform for zero-human companies. It is agent-runtime-agnostic: connect Claude, Cursor, OpenCode, Codex, Bash, or HTTP webhooks. As of v0.3.0, it supports adapters for Cursor, OpenCode, and Pi alongside the original runtime targets.

The feature set is built around governance infrastructure:

Org charts with reporting lines -- tasks cascade from company mission down to individual agent objectives, following the defined hierarchy
Heartbeat scheduling -- agents run on defined cadences, triggered by the platform rather than requiring user prompts
Per-agent monthly budgets -- each agent has a spending ceiling; exceeding it triggers automatic pausing
Governance with rollback and approval gates -- changes require approval before execution and can be rolled back afterward
Immutable audit logs -- every action is recorded and cannot be altered retroactively
Multi-company support -- manage multiple companies from a single instance

The upcoming Clipmart feature extends this with downloadable pre-built company templates: full org structures and agent configurations for marketing companies, e-commerce operations, software development, sales organizations, and media. The idea is to lower the setup barrier for "zero-human company" creation.

What Paperclip does not provide: agents. Domain knowledge. Opinions about what a legal agent should know, how a competitive intelligence scan should be structured, or why the brand guide the marketing agent creates should inform the content strategy the growth agent executes. Paperclip is a runtime for agents you define. It enforces constraints and routes work. The intelligence is your responsibility.

What Soleur Actually Is

Soleur is the Company-as-a-Service platform. 66 agents, 73 skills, and a compounding knowledge base organized across 8 business domains. Each domain has a director-level leader and specialist agents: the CMO orchestrates brand architects, SEO specialists, and growth researchers; the CLO manages legal document generation and compliance auditing; the CTO oversees engineering research, code review, architecture design, and deployment.

These agents do not operate in silos. They share a git-tracked knowledge base -- a directory of structured Markdown files -- that accumulates institutional memory with every session. The brand guide the brand-architect writes informs what the content writer generates. The competitive intelligence scan the CPO runs updates the sales battlecards the deal-architect uses. The legal compliance audit references the privacy policy the CLO previously documented. Knowledge flows across domains because every agent reads from and writes to the same base.

The orchestration model is the compound workflow lifecycle: brainstorm → plan → implement → review → compound. The compound step is what separates Soleur's approach architecturally: learnings from each session are routed back to the specific agents and workflows that were active, and critical failure patterns are promoted to mechanical enforcement hooks -- code-level guardrails that make known failure modes structurally impossible.

Soleur runs inside Claude Code. It is open-source and local-first: your knowledge base lives in your repository, your agents run in your environment, your credentials stay under your control.

The Core Distinction: Infrastructure vs. Intelligence

Paperclip solves the governance problem: how do you control autonomous agents operating without human oversight? Budget caps, approval gates, rollback capabilities, org hierarchy, and audit trails are the answer. These are genuine problems. Autonomous agents without constraints burn money and make irreversible decisions. Paperclip's feature set directly addresses this.

Soleur solves the knowledge problem: what should agents actually know and do? A marketing agent that does not understand brand voice, competitive positioning, and SEO strategy will produce content. Whether that content is good is a different question entirely. A legal agent without knowledge of the company's regulatory context will generate documents. Whether those documents are accurate and appropriately protective depends on domain depth that cannot be scaffolded from an org chart.

The gap in Paperclip's model is real: with 14,600 GitHub stars and no pre-built domain agents, the majority of setup time goes to defining agent behavior rather than extracting value from it. Clipmart will lower this barrier with company templates, but pre-built org structures still require users to fill in the actual domain intelligence -- the reasoning, the institutional context, the quality standards.

The gap in Soleur's model is equally real: the workflow lifecycle is purpose-built for Claude Code sessions initiated by a human. It does not offer Paperclip's heartbeat scheduling (agents running on autonomous cron cadences), per-agent budget enforcement, or multi-company governance. These are problems Soleur has not solved. Paperclip has.

The Compounding Difference

The deepest distinction between the two platforms is not which features appear in each list. It is whether the system gets smarter with use.

Paperclip tracks tasks, budgets, and audit logs. This produces valuable operational data. It does not feed back into agent behavior. An agent that exceeded its budget and was automatically paused does not learn from the experience. The governance layer enforces rules it was given; it does not discover new rules through operation.

Soleur's compound step changes this. From the project's engineering log:

An AI agent edited files outside its designated workspace. Two hours of work disappeared. The failure triggered a four-stage response: documentation, governance rule, enforcement hook, routing. The system can never make that mistake again.

The four-stage arc -- incident → rule → code-level guard → structural prevention -- has repeated across dozens of failure classes. The project's governance document started at 26 rules. It now contains 200+, each triggered by a real incident. When an agent makes a mistake, the compound step ensures neither that agent nor any agent will make it again. The knowledge base does not just record history -- it changes behavior.

Paperclip's rollback capabilities address damage after it occurs. Soleur's compound architecture prevents the damage by making recurrence structurally impossible. Both approaches are valuable; they operate at different points in the failure lifecycle.

What you need	Paperclip	Soleur
Governance and budget controls	Yes	Partial
Heartbeat scheduling (autonomous cron)	Yes	No
Rollback and approval gates	Yes	No
Pre-built domain agents	No	Yes
Compounding cross-domain knowledge base	No	Yes
Self-improving rules and guardrails	No	Yes
Workflow lifecycle (brainstorm through ship)	No	Yes
Open-source and local-first	Yes	Yes
Multi-company support	Yes	No

When Paperclip Is the Right Choice

Paperclip is the right choice when you need autonomous agent governance: the ability to run agents on schedules without user prompts, with defined budget ceilings and rollback controls. If you are building a zero-human company where agents operate continuously -- marketing agents posting on cadence, data agents refreshing reports overnight, operations agents monitoring spend -- Paperclip provides the governance layer that makes continuous autonomous operation safe.

If you already have domain agents -- built on Claude, Cursor, or another runtime -- and need orchestration infrastructure around them, Paperclip's org chart model and adapter ecosystem are a faster path than building governance from scratch.

Clipmart, when it ships, will make Paperclip more accessible for founders without existing agent libraries: downloadable company templates for marketing, e-commerce, software development, and other verticals. The quality of those templates will determine how much domain intelligence comes pre-built versus how much founders still need to supply.

When Soleur Is the Right Choice

Soleur is the right choice when the quality of what agents produce matters as much as the fact that they run.

A competitive intelligence scan that misses new entrants is worse than no scan. A legal compliance audit that cites outdated regulations creates false confidence. A content strategy that ignores brand positioning produces noise. These are not problems that governance controls solve -- they are problems that require domain depth, institutional memory, and the kind of cross-domain coherence that only compounds over time.

Solo founders building companies where legal, financial, and product strategy decisions carry real stakes cannot delegate those decisions to autonomous cycles and expect competitive-quality output. Soleur's 8-domain coverage includes the three domains Paperclip's comparable tools most commonly omit: legal, finance, and product strategy -- precisely because those domains require careful human-in-the-loop review, not autonomous execution.

If you work in Claude Code, want a full AI organization that accumulates knowledge about your specific business, and want every decision to make subsequent decisions better, Soleur's compound architecture is built for that use case.

Using Both

The complementary case is direct: Soleur provides domain intelligence; Paperclip provides governance infrastructure. Soleur's 66 agents could run within Paperclip's orchestration framework -- heartbeat-scheduled, budget-capped, with rollback controls -- while contributing to a compounding knowledge base that Paperclip's governance layer does not supply.

Paperclip's adapter model demonstrates this is architecturally feasible. v0.3.0 added adapters for Cursor, OpenCode, and Pi. A Soleur adapter would extend this pattern: Soleur's agents run as managed workers within Paperclip's org chart, governed by Paperclip's budget and scheduling controls, while the compound step continues building cross-domain institutional memory after each session.

An official Soleur adapter for Paperclip does not yet exist. The combination represents the most complete zero-human company stack either platform could offer.

FAQ

Q: Is Paperclip a competitor to Soleur?

Partially. Both target the AI company category, but they operate at different layers of the stack. Paperclip is governance infrastructure: org charts, budget controls, scheduling, rollback, audit logs. Soleur is domain intelligence: purpose-built agents, compounding knowledge base, workflow lifecycle. The most accurate framing is complementary -- Paperclip governs how agents run; Soleur defines what agents know and do. Direct competition begins if Clipmart ships company templates with deep, compounding domain intelligence, or if Soleur adds autonomous scheduling and budget enforcement.

Q: Does Paperclip include domain agents for legal, marketing, or finance?

No. Paperclip is agent-runtime-agnostic and does not include pre-built domain agents. It supports Claude, Cursor, OpenCode, Codex, Bash, and HTTP webhooks, but you supply your own agents and domain logic. The upcoming Clipmart feature will provide org structure templates for specific verticals, but the agents and their domain intelligence remain user-defined.

Q: What is zero-human company orchestration?

Zero-human company orchestration describes systems designed to run business operations autonomously -- agents handling scheduling, task execution, and decision-making without human intervention between cycles. Paperclip is built explicitly for this model, with heartbeat scheduling, approval gates, and budget controls to make continuous autonomous operation safe. Soleur takes a founder-in-the-loop approach: agents execute fully, but the founder makes decisions at key workflow gates rather than receiving a summary after the fact.

Q: Can Soleur and Paperclip be used together?

Yes. Soleur's domain agents could run as managed workers within Paperclip's orchestration framework, gaining heartbeat scheduling, per-agent budget controls, and rollback governance while contributing to the compounding knowledge base that Paperclip does not supply. An official adapter does not yet exist, but Paperclip's v0.3.0 adapter pattern (Cursor, OpenCode, Pi) makes this architecturally straightforward. The combination would represent the most complete open-source, self-hosted zero-human company stack available.

Q: What are the main open-source AI company platforms in 2026?

The two most prominent open-source, self-hosted platforms for AI company operation are Paperclip (MIT license, 14,600+ GitHub stars, governance infrastructure layer) and Soleur (open-source, 66 agents, domain intelligence layer). Polsia is the fastest-growing proprietary alternative -- $1.5M ARR with 2,000+ managed companies as of March 2026 -- but is cloud-hosted, closed-source, and fully autonomous by design.

Your AI Team Now Works From Your Actual Codebase

2026-03-29T00:00:00Z

Every AI development workflow has the same failure mode: the agent starts with a blank workspace. It does not know your architecture, your brand voice, your legal constraints, or what you shipped last week. You brief it from scratch every session. The context you build evaporates when the session ends.

Soleur agents now operate on your actual codebase. Connect your GitHub repository during onboarding, and every agent conversation starts with full project context — your decisions, your patterns, what you have built so far.

What Changed

The onboarding flow now includes a repository connection step. You have three options:

Connect an existing project. If you already have code on GitHub, install the Soleur GitHub App, select your repository, and your workspace is provisioned with your code. Your AI team reads your knowledge base, brand guide, specifications, and learnings from the first conversation.

Start fresh. If you are pre-code or starting a new venture, Soleur creates a private repository under your GitHub account. The workspace scaffolds a knowledge base structure from day one — brainstorms, specs, plans, and learnings directories ready for your first session.

Skip for now. Repository connection is optional. You can connect later from Settings.

The entire flow is designed for founders who may not be technical. Plain language, no jargon, clear explanations of what each step does and why.

How It Works

When you connect a repository, Soleur installs a GitHub App on your account. The app requests permission to read and manage your project files — nothing else. Your code stays in your GitHub account, under your control.

Behind the scenes:

Session start: Your workspace pulls the latest changes from your repository. If your team (or another agent) pushed changes since your last session, you get them automatically.
Session end: Any changes your AI team made — new specifications, updated brand guide, generated legal documents — are pushed back to your repository.
Sync is best-effort. A failed sync never blocks your session. If something goes wrong, the next session retries. Your work is never interrupted by a network hiccup or a merge conflict.

Authentication uses short-lived GitHub App installation tokens that expire after one hour. No long-lived credentials are stored in your workspace. The AI team accesses your repository through secure, scoped tokens that you can revoke at any time.

The Compounding Effect

Repository connection is not a convenience feature. It is the infrastructure that makes compound knowledge work in practice.

Every Soleur session produces artifacts: brainstorm documents capture design decisions. Plans encode implementation strategy. Learnings record what worked and what did not. Legal agents generate compliance documents. Marketing agents produce content briefs. All of these accumulate in your knowledge base.

Without repository connection, these artifacts exist only in a temporary workspace. They vanish when the session ends. With repository connection, they persist in your GitHub repository. The next session reads them. The session after that builds on them. Your AI team's institutional memory compounds across every conversation, every domain, every decision.

This is the difference between an AI that forgets and an AI team that learns.

What This Means for Your Workflow

Before repository connection, a typical Soleur session started with context-setting. You explained what you were building, what you had decided, what constraints applied. The AI team was capable but amnesiac.

Now, a typical session starts with the AI team already knowing:

Your project architecture and codebase
Your brand voice and messaging guidelines
Your legal documents and compliance requirements
Your product roadmap and strategic priorities
Every decision you have made in previous sessions

The founder's role does not change. You still make every decision. You still approve every output. But the starting point is different. Your AI team begins where the last session ended, not from zero.

Getting Started

New users see the repository connection flow during onboarding. Existing users can connect a repository from Settings.

The feature is live now. No waitlist, no beta, no pricing change. Repository connection is part of the Soleur open-source platform.

Q: Does Soleur access my private repositories?

The Soleur GitHub App accesses only the repositories you explicitly select during installation. You choose which repositories to grant access to, and you can modify or revoke that access at any time from your GitHub settings.

Q: What happens if I disconnect my repository?

Your workspace continues to function with the code and knowledge base already provisioned. You lose automatic sync — changes will not pull or push until you reconnect. No data is deleted.

Q: Can I use Soleur without connecting a repository?

Yes. Repository connection is optional. You can skip it during onboarding and connect later, or use Soleur with a standalone workspace. The AI team works in both modes — repository connection adds persistence and compounding across sessions.

Q: What if I do not have a GitHub account?

The onboarding flow requires a GitHub account for repository connection. If you choose "Start Fresh," Soleur creates the repository under your GitHub account. GitHub offers free accounts with unlimited private repositories.

Q: Is my code sent to third parties?

Your code stays in your GitHub account and in your local Soleur workspace. Soleur agents read your codebase to understand context. The code itself is processed by Anthropic's Claude models under their data retention policies. No code is stored on Soleur servers or shared with other parties.

Credential Helper Isolation: Secure Git Auth in Sandboxed Environments

2026-03-29T00:00:00Z

Sandboxed AI agents need to push and pull from git repositories. The agent runs in a constrained environment. It must not hold long-lived credentials. It must not be able to access repositories beyond its scope. And the authentication mechanism must be invisible to the agent — no interactive prompts, no manual token entry, no environment variable leakage.

This is the credential helper isolation pattern we built for Soleur's repository connection feature.

The Problem

A Soleur agent session needs to:

Pull the latest changes from the user's GitHub repository at session start
Push any changes the agent made at session end
Do both without storing credentials in the workspace, the environment, or any file the agent can read

The standard approaches fail in this context:

Personal Access Tokens (PATs) are long-lived, user-scoped, and grant access to every repository the user owns. A leaked PAT in a sandboxed environment is a full-scope credential compromise. PATs also require the user to generate and manage tokens manually — a friction point for non-technical founders.

Deploy keys are repository-scoped but SSH-based, require key pair management, and cannot be rotated programmatically. They also grant permanent access until manually revoked.

OAuth tokens require an interactive browser flow that cannot run inside a headless agent session. The token refresh cycle adds complexity without solving the scope problem.

GitHub App installation tokens are the right fit: automatically scoped to the repositories the user selected during app installation, expire after one hour, and can be generated programmatically from a server-side JWT.

The Credential Helper Pattern

Git supports custom credential helpers via the GIT_ASKPASS environment variable or the credential.helper configuration option. A credential helper is any executable that outputs username and password lines when git needs authentication.

The pattern:

Generate a short-lived GitHub App installation token on the server
Write a temporary shell script that echoes the token as git credentials
Pass the script path to git via -c credential.helper=!<path>
Run the git operation (clone, pull, or push)
Delete the credential helper in a finally block

Here is the credential helper writer from session-sync.ts:

function writeCredentialHelper(token: string): string {
  const helperPath = randomCredentialPath();
  writeFileSync(
    helperPath,
    `#!/bin/sh\necho "username=x-access-token"\necho "password=${token}"`,
    { mode: 0o700 },
  );
  return helperPath;
}

The x-access-token username is GitHub's convention for installation token authentication. The shell script is executable (0o700) and owned by the process user.

The cleanup is unconditional:

function cleanupCredentialHelper(helperPath: string): void {
  try {
    unlinkSync(helperPath);
  } catch {
    // Best-effort cleanup
  }
}

Every git operation wraps the credential lifecycle in a try/finally:

let helperPath: string | null = null;
try {
  const token = await generateInstallationToken(installationId);
  helperPath = writeCredentialHelper(token);

  execFileSync("git", [
    "-c", `credential.helper=!${helperPath}`,
    "pull", "--no-rebase", "--autostash",
  ], { cwd: workspacePath, stdio: "pipe", timeout: 60_000 });
} catch (err) {
  log.warn({ err, userId }, "Sync pull failed — continuing with local state");
} finally {
  if (helperPath) cleanupCredentialHelper(helperPath);
}

The credential helper exists on disk for the duration of the git operation — seconds for pulls and pushes, up to two minutes for initial clones. After the finally block, the token is gone.

Security Hardening

Randomized paths prevent symlink attacks

If the credential helper path were predictable (e.g., /tmp/git-credentials), an attacker with write access to /tmp could plant a symlink before the helper is written. The writeFileSync call would follow the symlink and overwrite the target file, or the attacker could read the token from the known path.

The path uses crypto.randomUUID():

export function randomCredentialPath(): string {
  return `/tmp/git-cred-${randomUUID()}`;
}

The UUID is generated by Node's crypto module, which uses the operating system's cryptographic random number generator. The path is unpredictable — an attacker cannot race the write.

UUID validation prevents path traversal

Every function that takes a userId parameter validates it against a UUID regex before constructing file paths:

const UUID_RE = /^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/i;

if (!UUID_RE.test(userId)) {
  throw new Error(`Invalid userId format: ${userId}`);
}

const workspacePath = join(getWorkspacesRoot(), userId);

Without this check, a userId of ../../etc would construct a workspace path outside the expected directory. The UUID regex enforces that userId contains only hex characters and hyphens — no path separators, no dots, no special characters.

Token expiry limits blast radius

GitHub App installation tokens expire after one hour. The token cache adds a five-minute safety margin:

const TOKEN_SAFETY_MARGIN_MS = 5 * 60 * 1000;

const cached = tokenCache.get(installationId);
if (cached && cached.expiresAt > Date.now() + TOKEN_SAFETY_MARGIN_MS) {
  return cached.token;
}

If a token leaks despite the randomized paths and immediate cleanup, the exposure window is at most 55 minutes. Compare this to a PAT, which has no expiry by default.

GitHub App JWT Flow

Installation tokens are exchanged from a JWT signed with the GitHub App's private key. The JWT is built with Node's crypto module — no external JWT library:

function createAppJwt(): string {
  const now = Math.floor(Date.now() / 1000);
  const header = { alg: "RS256", typ: "JWT" };
  const payload = {
    iss: getAppId(),
    iat: now - 60,   // Clock skew tolerance
    exp: now + 10 * 60, // 10-minute JWT lifetime
  };

  const headerB64 = base64url(Buffer.from(JSON.stringify(header)));
  const payloadB64 = base64url(Buffer.from(JSON.stringify(payload)));
  const signingInput = `${headerB64}.${payloadB64}`;

  const signer = createSign("RSA-SHA256");
  signer.update(signingInput);
  signer.end();
  const signature = base64url(signer.sign(getPrivateKey()));

  return `${signingInput}.${signature}`;
}

The JWT has a 10-minute lifetime. The iat is backdated by 60 seconds to handle clock skew between the server and GitHub's API. The private key is loaded from an environment variable (GITHUB_APP_PRIVATE_KEY) stored in Doppler — it never touches the workspace or the agent sandbox.

The JWT is exchanged for an installation token via GitHub's REST API:

const response = await githubFetch(
  `${GITHUB_API}/app/installations/${installationId}/access_tokens`,
  {
    method: "POST",
    headers: { Authorization: `Bearer ${jwt}` },
  },
);

The returned token is cached in memory with its expiry timestamp. Subsequent operations within the same server process reuse the cached token until five minutes before expiry.

Best-Effort Sync Philosophy

The sync operations follow a strict principle: a failed sync is recoverable; a blocked session is not.

Both syncPull and syncPush catch all errors and log warnings instead of throwing:

export async function syncPull(
  userId: string,
  workspacePath: string,
): Promise<void> {
  // ... setup ...
  try {
    // ... pull logic ...
  } catch (err) {
    log.warn({ err, userId },
      "Sync pull failed — continuing with local state");
  } finally {
    if (helperPath) cleanupCredentialHelper(helperPath);
  }
}

If the pull fails — network outage, token error, merge conflict — the session starts with whatever local state exists. The agent works against a slightly stale codebase rather than not starting at all.

If the push fails, the commit message includes context for the next session:

log.warn({ err, userId },
  "Sync push failed — next session will retry");

The next syncPull auto-commits any local changes before pulling, so work that accumulated between sessions — whether or not the previous push succeeded — is preserved.

Why merge instead of rebase

The pull uses --no-rebase:

execFileSync("git", [
  "-c", `credential.helper=!${helperPath}`,
  "pull", "--no-rebase", "--autostash",
], { cwd: workspacePath, stdio: "pipe", timeout: 60_000 });

Shallow clones (--depth 1) lack sufficient history for rebase operations. A rebase against a shallow clone can fail unpredictably when the common ancestor is not in the local history. Merge is the safe default — it produces a merge commit but never fails due to missing history.

The --autostash flag handles the case where the agent has uncommitted changes that the auto-commit missed (e.g., files matching .gitignore patterns that were later un-ignored).

The Full Lifecycle

Putting it together, the credential lifecycle for a single agent session:

Session start: Server calls syncPull(userId, workspacePath)
syncPull fetches the user's github_installation_id from the database
generateInstallationToken signs a JWT with the App's private key, exchanges it for an installation token, caches the result
writeCredentialHelper writes the token to a randomized /tmp path
Git pulls using the credential helper, merging remote changes
cleanupCredentialHelper deletes the helper script
Agent session runs — all git operations within the session use the workspace's existing git config (no credentials needed for local operations)
Session end: Server calls syncPush(userId, workspacePath)
Steps 3-6 repeat for the push operation
The installation token expires within the hour. The credential helper no longer exists on disk.

At no point does the agent sandbox contain a reusable credential. The token exists in a shell script for the duration of a git command — milliseconds to seconds. The shell script path is unpredictable. The token itself expires.

Q: Why not use GIT_ASKPASS instead of credential.helper?

GIT_ASKPASS works but requires setting an environment variable that persists for the duration of the process. The -c credential.helper=!<path> flag is scoped to a single git invocation. If the process spawns other git operations (e.g., the agent running git commands), they do not inherit the credential helper.

Q: What happens if the credential helper is not cleaned up?

The token in the helper expires after one hour regardless. The randomized filename means it cannot be targeted without directory listing access. But the finally block ensures cleanup in all normal and exceptional exit paths — the only scenario where cleanup fails is a hard process kill (SIGKILL), in which case the file persists until the next /tmp cleanup cycle.

Q: Why not use GitHub's built-in credential caching?

GitHub's credential.helper store and credential.helper cache persist credentials across git invocations — the opposite of what we want. The isolated helper pattern ensures credentials exist only for the duration of one operation.

Q: Does the shallow clone limit what agents can do?

Shallow clones (--depth 1) lack full git history. Agents cannot run git log with history beyond the latest commit, git blame across old revisions, or rebase against distant ancestors. For the intended use case — reading and modifying current project state — shallow clones are sufficient. The trade-off is clone speed (seconds vs. minutes for large repositories) against history depth.

Soleur vs. Polsia: Two Architectures for Running a Company with AI

2026-03-26T00:00:00Z

Polsia hit $1.5M ARR with 2,000+ managed companies as of March 2026. Solo founder Ben Broca built an AI platform that runs companies on autopilot -- nightly autonomous cycles where AI agents evaluate company state, set priorities, execute tasks, and send a morning summary to the human who technically owns the company. The growth is real. The category is validated.

The question is what kind of company you want to build.

Polsia and Soleur both operate in the Company-as-a-Service space. Both use Anthropic models. Both aim to reduce the operational burden on solo founders. But their underlying architectures reflect fundamentally different answers to the same question: what should the founder's role be when AI runs the company?

What Each Platform Is

Polsia is a fully autonomous AI company-operating platform. Its architecture centers on role-based agents -- a CEO agent, an Engineer agent, a Growth Manager agent -- that run nightly autonomous cycles. Each cycle evaluates the company's current state, decides what to prioritize, executes the tasks, and delivers a summary. The founder receives a morning briefing. Polsia provisions all infrastructure: email servers, databases, Stripe, GitHub. The philosophy, in founder Ben Broca's words: "80% AI, 20% taste."

Polsia is built on the Claude Agent SDK (Claude Opus 4.6) and is cloud-hosted and proprietary. Pricing as of March 2026 is $29-59/month, with a potential revenue share component (previously 20% of business revenue and 20% of managed ad spend -- whether this applies to current tiers should be confirmed directly with Polsia).

Polsia covers five business domains: engineering, marketing, cold outreach, social media, and Meta ads.

Soleur is a Company-as-a-Service platform. It deploys 66 agents across 8 business departments -- engineering, marketing, legal, finance, operations, product, sales, and support -- with a compounding knowledge base that accumulates institutional memory across every session and every domain. Soleur runs inside Claude Code.

Soleur is open-source (Apache 2.0). The platform is free.

The founding philosophy: you decide. Agents execute. Knowledge compounds.

The Philosophical Divide

This is not a features comparison. It is an architecture comparison rooted in a philosophical question: should AI replace founder judgment or amplify it?

Polsia answers: replace it. The CEO agent decides what to prioritize. The Growth Manager decides what to post. The Engineer decides what to build. The founder receives a summary and, implicitly, approves by not intervening. The "20% taste" the founder retains is more editorial veto than active decision-making.

Soleur answers: amplify it. Every Soleur workflow -- brainstorm, plan, implement, review, compound -- requires a human decision gate. The marketing agent drafts a campaign; the founder approves before anything publishes. The legal agent generates a compliance analysis; the founder reviews before the policy changes. The competitive intelligence agent surfaces a new threat; the founder decides how to respond before the strategy shifts. The AI handles 100% of execution. The founder provides 100% of judgment.

Neither answer is wrong in the abstract. The right architecture depends on what you are trying to build and what role you want to play in building it.

Where They Differ

Domain Coverage

Polsia covers five domains. Soleur covers eight.

The three domains Polsia omits -- legal, finance, and product strategy -- are not peripheral. A privacy policy violation can trigger regulatory action. A financial model error can burn the runway. A product roadmap that ignores competitive positioning can make the engineering investment worthless. These are the decisions with the highest downside risk and the greatest need for human judgment.

Soleur's legal agents generate compliance documents, audit existing policies, and flag regulatory exposure. Its finance agents produce budget analysis, revenue projections, and board-ready financial reports. Its product agents run spec reviews, competitive positioning analyses, and UX validation. These domains are absent from Polsia's platform -- not because they are unimportant, but because full automation of high-stakes legal and financial decisions carries risks the autonomous model cannot absorb.

Knowledge Architecture

Polsia's agents operate in nightly cycles. Each cycle begins from the current company state -- what exists in the connected infrastructure -- not from an accumulated body of institutional knowledge. An engineering decision from last month does not inform the growth strategy this week. A brand positioning session does not shape the cold outreach copy. The agents execute within their domain; context does not compound across domains.

Soleur's compounding knowledge base is cross-domain by architecture. The brand guide written by the brand-architect agent informs every piece of marketing copy. The competitive intelligence scan updates sales battlecards. The legal compliance agent references the privacy policy when engineering ships a new data feature. The knowledge base is a git-tracked directory of Markdown files -- readable, auditable, and editable by the founder directly -- that accumulates across every session in every domain.

The first time Soleur's competitive intelligence agent runs, it builds a baseline. The twentieth time, it compares against nineteen prior scans, surfaces new entrants, flags shifted pricing, and updates downstream artifacts automatically. The compounding is a structural property of how the knowledge base is written and read, not a marketing claim.

Polsia runs your company cycle by cycle. Soleur builds organizational intelligence that compounds over time.

Workflow Orchestration

Polsia's workflow is a nightly cron job: evaluate state, set priorities, execute tasks, send summary. It is event-triggered and scope-limited to each domain's autonomous cycle. The decision-making is opaque -- the founder does not see why the CEO agent chose to prioritize feature X over feature Y, or why the Growth Manager sent that particular cold email to that particular list.

Soleur runs structured lifecycle workflows: brainstorm > plan > implement > review > compound. Every stage produces an artifact the founder can read, modify, and approve. The plan is visible before execution starts. The review happens before anything ships. The compound step captures what was decided and why, building institutional memory that informs the next decision in the same domain and every adjacent domain.

The difference between an autonomous cron job and an organizational workflow is transparency and the context that flows between stages. Polsia optimizes for founder hands-off-ness. Soleur optimizes for founder leverage.

Pricing

Polsia's pricing as of March 2026:

Entry tier: $29/month
Higher tier: $59/month
Revenue share: Historically 20% of business revenue and 20% of managed ad spend (current applicability should be confirmed with Polsia)

Soleur is open-source. The platform is free.

The pricing analysis matters because of the revenue share dimension. A solo founder generating $10,000/month in revenue would pay $2,000/month under a 20% revenue share model -- on top of the subscription fee. A founder running $5,000/month in Meta ads would pay an additional $1,000/month in ad management fees. At any meaningful revenue, the true cost of Polsia's autonomous model could significantly exceed the headline $29-59/month.

Soleur's planned paid tier carries a flat rate with no revenue share. You keep everything you earn.

Infrastructure Control

Polsia provisions all infrastructure: email servers, databases, Stripe, GitHub. This convenience is part of the fully autonomous model -- the platform owns the stack on your behalf. For founders who want zero setup friction, this is a genuine feature.

Soleur operates on infrastructure you control. You choose your hosting provider, your database, your payment processor. Soleur's agents run in your environment, on your infrastructure, with your credentials. For founders building companies where data privacy, infrastructure portability, or vendor independence matters, controlling the stack is not optional.

When Polsia Is the Right Choice

Polsia is well-suited for founders who want maximum automation with minimal involvement. If you are testing a business concept, want a low-touch experiment running in parallel with other work, or explicitly want AI making most of the operating decisions, Polsia's architecture is designed for that use case. The nightly cycle, morning summary, and infrastructure provisioning minimize the cognitive overhead of running an autonomous operation.

If you accept the "80% AI, 20% taste" philosophy, Polsia executes it cleanly.

When Soleur Is the Right Choice

Soleur is the right choice when the quality of decisions matters as much as the speed of execution.

Solo founders building companies where brand precision, legal compliance, financial planning, and product strategy are differentiators cannot hand those decisions to an autonomous system and expect competitive-quality output. The first billion-dollar solo company will not be built on autopilot. It will be built by a founder whose judgment is amplified across every domain -- where every decision makes the system smarter, and every new project benefits from everything the company has learned.

If the business you are building requires legal rigor, financial modeling, product strategy, or cross-domain institutional memory that compounds over time, Soleur covers those requirements. Polsia does not.

The distinction is not automation versus manual work. Both platforms automate execution. The distinction is who provides the judgment: the AI or the founder.

FAQ

Q: Can I use Polsia and Soleur together?

Yes, in principle. Polsia automates the operational cycles for the domains it covers. Soleur can handle the domains Polsia omits -- legal, finance, product strategy -- and provide the cross-domain knowledge infrastructure those decisions require. The architectures do not conflict; they address different scopes and different philosophies within those scopes.

Q: Polsia's CEO agent decides priorities. Doesn't that make human-in-the-loop more efficient, not less?

Only if the autonomous decisions are reliably good. The efficiency argument for fully autonomous operation holds when the marginal cost of a wrong decision is low. When decisions carry legal, financial, or strategic consequences -- a contract clause, a pricing model, a product roadmap -- the cost of a wrong autonomous decision can exceed the time saved by not reviewing it. Soleur's position is that founder judgment is the compounding asset, not an inefficiency to be automated away.

Q: Polsia reached $1.5M ARR. Doesn't that prove autonomous CaaS works?

Polsia's growth validates that solo founders will pay for AI-powered company operation. It validates the CaaS category thesis. What $1.5M ARR across 2,000+ managed companies does not validate is the output quality of autonomous execution, the long-term trajectory of companies running on that model, or whether the autonomous approach produces results competitive with human-guided execution at higher stakes. The market exists. The architecture question remains open.

Q: Is Soleur's open-source model sustainable against a venture-backed competitor?

Soleur's compounding knowledge base, cross-domain institutional memory, and open-source transparency are structural advantages that a proprietary cloud platform cannot replicate by adding features. The open-source core means every agent, every skill, and every knowledge-base schema is auditable and extensible. The compound architecture means the platform gets better with use in a way that autonomous nightly cycles do not. Sustainability comes from the depth of the moat, not the size of the funding round.

Vibe Coding vs Agentic Engineering: What Solo Founders Need to Know

2026-03-24T00:00:00Z

In February 2025, Andrej Karpathy gave developers permission to stop overthinking and start shipping. He called it vibe coding: describe what you want, accept the AI's output, iterate fast. For prototypes and solo builders, it was a revelation.

Exactly one year later, Karpathy introduced agentic engineering — the practice of orchestrating AI agents with human oversight rather than prompting models directly. The name stuck. The shift it described was real.

The difference between these two approaches is not a matter of preference. For a solo founder trying to build at company scale, it is the difference between a system that stays helpful and one that compounds.

The Core Difference

Vibe coding is conversation. Agentic engineering is delegation with accountability.

In vibe coding, you prompt a model conversationally. You describe what you want, the model generates output, you accept or reject. The session ends. The next session starts fresh. No memory of what worked, what broke, or what to avoid.

Agentic engineering is different by design. You define specifications before any code is written. Agents execute against those specs with verification gates that catch regressions. Quality checks run automatically. When something breaks, the failure is documented — not just remembered, but captured in a form the next session can learn from.

Dimension	Vibe Coding	Agentic Engineering
Entry point	Conversation	Specification
Memory	Single session	Persistent across sessions
Quality assurance	Manual review	Automated gates
Failure handling	Learn and move on	Document, route, enforce
Parallelization	One agent at a time	Multiple agents, isolated workspaces
Knowledge growth	Resets each session	Compounds with every task

What Vibe Coding Gets Right

Nothing in this comparison is an argument against vibe coding. It changed how solo founders build prototypes.

Before vibe coding, building a working prototype required hours of context-switching between editor, documentation, and the model. Vibe coding collapsed those context switches into one conversation. For discovery work — figuring out whether something is worth building at all — it remains the fastest tool available.

The problem is not the approach. The problem is what happens after you decide to build for real.

Where Vibe Coding Breaks

The plateau arrives fast.

You have a working prototype. The vibes were good. Now you need to add a feature, fix a regression, or hand the codebase to another agent for review. And the first thing you realize is that the hundredth session starts from the same blank slate as the first.

The model does not remember why you made that architectural decision. It does not know that approach was tried and failed three days ago. It does not know which edge cases your tests cover or which parts of the codebase are fragile. Every session is a reconstruction.

This is not a model limitation. It is a structural problem with session-based development: no specification means no ground truth. No persistent knowledge means no cumulative improvement. The sessions accumulate, but the system does not get smarter.

What Agentic Engineering Solves

Agentic engineering reframes the problem. Instead of asking "what can I build with AI today?" it asks "how does this system get better with every task I complete?"

Three structural changes drive this:

Specifications before execution. Writing what you intend to build before building it creates a contract between you and the agent: this is the outcome, these are the constraints, this is how success is measured. The agent executes against the spec. You verify against the spec. Both parties know what done looks like.

Verification gates. Agentic engineering builds review steps into the workflow itself. Automated tests run before merge. Plan review runs before implementation. Code review runs before the PR is opened. These gates are not bureaucracy — they are the mechanism by which the system catches its own mistakes before they become technical debt.

Persistent knowledge. When a session generates a learning — about what works, what fails, what to prevent — that learning gets captured and routed back into the system's rules and workflows. Not just remembered by the founder. Not just written in a comment. Enforced by the system, permanently.

The Solo Founder Multiplier

For a solo founder, the distinction between these approaches carries more weight than it does for a team.

A team absorbs vibe coding's memory problem through human coordination. The senior engineer remembers the architectural decisions. The QA specialist catches the regressions. Code review creates accountability even without automated gates.

A solo founder has none of those redundancies. When the session ends, nothing remembers what happened. When a regression appears three weeks later, there is no one to ask. When an agent makes the same mistake for the fourth time, there is no institutional memory to stop it.

Agentic engineering addresses these gaps directly. Specifications replace team meetings. Persistent knowledge replaces institutional memory. Automated gates replace the code review team that does not exist.

This is why compound knowledge matters more for solo founders than for anyone else. A system that gets smarter with each task is not a convenience — it is the only path to building at company scale without a company.

Beyond Engineering: The Full Picture

Vibe coding solves the coding problem. Agentic engineering solves the engineering problem. Neither addresses the other functions of running a company.

Legal documents need review. Marketing campaigns need execution. Competitive intelligence needs monitoring. Financial models need updating. These functions do not get better by coding faster. They get better when knowledge compounds across all of them — when the legal review informs the product positioning, when the competitive analysis shapes the pricing decision, when the engineering architecture reflects the compliance requirements.

This is the premise behind Company-as-a-Service — a model where a single AI organization runs every department of a business, with a compounding knowledge base that every department reads from and writes to. Agentic engineering is not just a better way to code. It is the architectural pattern for every function in the company.

Start Building

The shift from vibe coding to agentic engineering is not about working harder. It is about building a system that gets easier to operate over time.

Every specification written is a decision documented. Every automated gate is a failure mode permanently closed. Every learning captured is a session that starts more informed than the last.

The first billion-dollar company run by one person is not built in one session. It is built by a system that compounds.

Start building →

Frequently Asked Questions

What is vibe coding?

Vibe coding is an approach to AI-assisted development coined by Andrej Karpathy in February 2025. It describes ad-hoc, conversational AI coding: describe what you want, accept the model's output, iterate without formal specifications or quality gates. It prioritizes speed for prototyping and exploratory work.

What is agentic engineering?

Agentic engineering is the structured orchestration of AI agents with human oversight, introduced by Andrej Karpathy in February 2026. It emphasizes formal specifications before execution, automated verification gates, persistent memory across sessions, and knowledge that compounds with every task completed.

Which approach is better for solo founders?

Both approaches serve different purposes. Vibe coding is faster for prototyping and validating ideas. Agentic engineering is better suited for production systems that need to remain maintainable over time. Solo founders benefit most from agentic engineering because they lack the team redundancies — institutional memory, code review, QA — that compensate for session-based development's limitations.

How does compound engineering relate to agentic engineering?

Compound engineering is a specific implementation of agentic engineering's knowledge-persistence principle. Where agentic engineering establishes that learnings should persist across sessions, compound engineering describes the specific loop: work, capture the learning, route it back to the relevant workflow, and enforce it mechanically when possible. Compound engineering is what agentic engineering looks like when knowledge growth becomes the primary architectural goal.

Can solo founders use vibe coding and agentic engineering together?

Yes. Many effective solo founder workflows use vibe coding for exploration and prototyping, then transition to agentic engineering for production implementation. The specification written at the start of agentic engineering captures what the vibe coding prototype proved worth building. The two approaches are complementary at different stages of the same project lifecycle.

AI Agents for Solo Founders: The Definitive Guide

2026-03-24T00:00:00Z

Solo-founded startups rose from 23.7% to 36.3% of all new ventures between 2019 and the first half of 2025, according to the Carta Solo Founders Report. The reason is not courage. It is infrastructure. AI tools now handle work that used to require a team — and most solo founders discover them the same way: a demo of something that writes code, generates copy, or drafts a legal template. It saves an hour. Then two. Then the plateau arrives.

The problem is not the tools. The problem is that running a company requires eight distinct domains — engineering, marketing, legal, finance, operations, product, sales, and support — and a collection of single-function tools never adds up to a working organization.

AI agents are different. An agent does not wait for prompts. It operates with a goal, uses tools to execute, and works alongside other agents toward a shared objective. For a solo founder, the difference is the difference between a faster keyboard and an actual organization.

This guide is for founders who have moved past the demo. You have seen what AI can do for one function. Now you want to understand what it means to run an entire company with agents — and what separates the approaches that scale from the ones that plateau.

What Makes an AI Agent Different

A chatbot answers a question. An AI agent completes a task.

The distinction sounds semantic until you try to ship something. A chatbot can explain how to write a terms of service. An agent writes the terms of service, checks it against your jurisdiction's requirements, flags clauses for review, and files a task to revisit it when regulations change. The output is not a response — it is a work product.

Four properties define a true agent:

Goal-orientation. The agent has a defined outcome, not just a prompt. It knows what done looks like and works toward it.

Tool use. The agent can read files, write code, search the web, make API calls, and coordinate with other agents. It is not limited to generating text.

Memory. The agent can access context from previous sessions — prior decisions, known constraints, existing work products, and accumulated learnings.

Accountability. The agent's output can be verified against a specification. This matters more for solo founders than for teams, because there is no one else checking. An agent without an accountability mechanism is a sophisticated autocomplete.

The Eight Domains of a Company

Running a company requires expertise across eight distinct domains. The Bureau of Labor Statistics describes the core duties of top executives as planning strategies, coordinating activities, and communicating with stakeholders — functions that span every department. No founder — and no AI tool — is competent in all eight from day one. The question is how you close the gaps.

Engineering builds and ships the product. Code review, architecture decisions, infrastructure provisioning, test coverage, release management.

Product translates user need into specification. Feature prioritization, user research, UX decisions, business validation, roadmap management.

Marketing creates demand. Brand voice, content strategy, SEO, social distribution, competitive positioning.

Legal manages exposure. Contract drafting, compliance monitoring, privacy policy, terms of service, IP protection, regulatory updates.

Finance models the business. Revenue forecasting, expense tracking, burn rate, unit economics, pricing decisions.

Operations keeps the machine running. Vendor management, process documentation, tooling reliability, infrastructure maintenance.

Sales converts attention into revenue. Outbound strategy, pipeline management, deal architecture, revenue operations.

Support retains customers and closes the feedback loop. Ticket triage, community management, knowledge base maintenance.

A solo founder with a collection of coding tools has handled one domain. The other seven are still manual.

Why Point Solutions Fail

The promise of solopreneur AI tools is speed. A code generator writes code faster. A copywriting tool drafts faster. A contract template saves legal fees. Each tool delivers on its narrow promise — and investors have noticed. Cursor reached $1 billion in annual recurring revenue proving that founders will pay for AI that accelerates a single domain.

What these tools cannot deliver is coordination.

Legal cannot reference what marketing published. Marketing cannot reflect what engineering decided. Engineering cannot anticipate what compliance requires. Each domain operates in isolation, which means the same decision gets made — and sometimes reversed — across multiple contexts without any of them knowing.

This is not a workflow problem. It is an architecture problem. Point solutions are stateless by design. They begin fresh with each session, in each domain, with each tool. The knowledge one function generates never reaches the others.

For a team, this is manageable. Team members talk. A senior engineer remembers the architectural decisions that constrained the marketing roadmap. The legal counsel reads the product brief before drafting the contract. The institutional memory lives in people.

A solo founder has none of that coordination infrastructure. Every handoff between domains requires the founder to carry the context manually. As the company grows, the cost of those handoffs grows with it.

What to Look For in AI Agents

Not every AI agent is useful for a solo founder. The properties that matter most differ from what matters in enterprise deployments.

Cross-domain context. The most important question to ask about any AI agent stack: what does the marketing agent know about what the engineering agent decided last week? If the answer is "nothing," you have a collection of tools, not an organization.

Persistent knowledge. Agents that start from a blank slate on each session require the founder to re-supply context manually every time. Agents with persistent memory across sessions accumulate knowledge and reduce the founder's coordination cost over time. This distinction compounds — a system that remembers three months of decisions is dramatically more useful than one that forgets at session end.

Verifiable output. An agent's output should be checkable against a specification. Quality gates built into the workflow replace the code review, legal review, and editorial review that a team provides. Without those gates, the founder becomes the bottleneck for every domain, every time.

Compound improvement. The most valuable agents get better with use. Each task generates a learning. Each learning routes back into the system's rules. Each subsequent task starts from a more informed baseline. An agent that performs at the same level after 100 tasks as it did after 10 is a tool with a more complicated interface.

The Compound Knowledge Advantage

The gap between a useful AI stack and a scalable one comes down to what happens to knowledge after a task is complete.

Most AI tools discard it. The session ends. The output remains. The reasoning that produced the output — the decisions made, the tradeoffs considered, the edge cases encountered — disappears.

Compound knowledge captures it. Every task generates a learning. The learning is routed to the domain where it belongs — engineering rules, marketing constraints, legal requirements. The next task in that domain starts with that learning already incorporated.

For a solo founder, compound knowledge solves the coordination problem that point solutions cannot. When the legal agent captures a compliance requirement, it does not just document it — it enforces it in every future task that touches the affected domain. When the engineering agent learns that a particular integration is fragile, every future task that depends on it starts with that warning already in place.

Over time, the AI organization does not just remember more. It makes better decisions, catches more edge cases, and requires less founder intervention. The founder's job shifts from doing and coordinating to deciding and directing.

Dario Amodei, CEO of Anthropic, predicted a 70-80% probability that a one-person billion-dollar company would emerge by 2026. That prediction is not about better tools. It is about compound knowledge — the only mechanism that turns a solo founder into an organization that improves structurally with every task.

This is why agentic engineering matters more for solo founders than for anyone else. A system that gets smarter with each task is not a convenience — it is the only path to building at company scale without a company.

What a Full AI Organization Looks Like

Company-as-a-Service is the model where a single AI organization covers all eight domains with agents that share a compounding knowledge base. The concept is no longer theoretical. Sam Altman, CEO of OpenAI, described a betting pool among tech CEOs for "the first year that there is a one-person billion-dollar company." TechCrunch reported that AI agents could birth the first one-person unicorn — but only if they extend beyond engineering into every function a company needs. Alibaba Group President J. Michael Evans went further, telling Fortune that agentic AI is making the one-person unicorn a near-term reality.

In practice, a full AI organization means:

An engineering review that checks code against the product spec, the legal constraints, and the compliance requirements — simultaneously, without the founder acting as the relay
A marketing brief that automatically reflects the latest competitive intelligence from the product and engineering teams
A contract draft that incorporates the business model, jurisdiction requirements, and pricing decisions already captured in the knowledge base
A financial report that draws on operational data, sales pipeline, and engineering velocity to produce an accurate view of the business

Each of these is an agent operating within shared context. The result is an organization that behaves coherently across domains — not because the founder coordinated the handoffs, but because the knowledge base did.

Soleur is built on this model: 63 agents across 8 departments, sharing a knowledge base that compounds with every task completed.

Getting Started

The path from solo founder to AI organization does not begin with replacing all your tools at once. It begins with establishing the knowledge layer.

Step 1: Define your knowledge base. Document what your company knows: the architecture decisions, the brand voice, the legal constraints, the pricing model. This is the ground truth every agent reads from and writes to.

Step 2: Start with one domain. Pick the domain where manual work costs you the most. Engineering is the natural starting point for technical founders, but marketing, legal, and finance are equally valid entry points. Deploy agents there first. Let the knowledge compound.

Step 3: Connect the domains. Once one domain is running, introduce the adjacent ones. The key is ensuring agents share context — a marketing agent that knows what engineering decided, a legal agent that knows what marketing published. The connections matter more than the individual capabilities.

Step 4: Build the feedback loop. Every task should generate a learning. Every learning should route back into the relevant domain's rules. The system should be measurably more effective after 100 tasks than after 10.

The goal is not AI tools that make you faster today. It is an AI organization that makes you more capable every month.

Start building →

Frequently Asked Questions

What is an AI agent for a solo founder?

An AI agent is a system that operates with a defined goal, uses tools to complete tasks, maintains memory across sessions, and can be verified against a specification. For solo founders, agents replace team functions that a single person cannot fill alone — code review, legal review, marketing execution, financial modeling — while sharing context across all domains so the organization behaves coherently.

How are AI agents different from AI tools like chatbots or coding assistants?

Most AI tools are session-based and single-function. They generate responses to prompts but do not maintain memory, execute multi-step workflows, or coordinate with other tools. AI agents are designed to complete tasks, not just answer questions. The best agents accumulate knowledge over time so each subsequent task benefits from everything the system has previously learned.

What are the most important solopreneur AI tools in 2026?

The highest-leverage agents cover the functions a solo founder cannot easily replicate: code review, legal document generation, competitive intelligence monitoring, financial modeling, and marketing execution. But individual agent capability matters less than cross-domain coordination. An agent stack where each domain shares context with the others compounds faster than a collection of specialized tools that cannot communicate.

How does compound knowledge work in practice?

Compound knowledge means every task generates a learning, and every learning is routed back into the relevant domain's rules or constraints. If the legal agent learns your jurisdiction requires a specific clause in employment agreements, that requirement is captured and applied to every future contract automatically. If the engineering agent encounters a fragile integration, that knowledge is documented and every future task touching the same integration starts with the warning already in place. The system improves structurally, not just incrementally.

Is Soleur only for technical founders?

No. Soleur covers all eight departments of a company — engineering, marketing, legal, finance, operations, product, sales, and support. Many founders start with the engineering domain, but legal, marketing, finance, and product agents operate independently and compound knowledge in their own domains. A founder with no engineering background can start with marketing or legal and build from there.

How do I get started with AI agents as a solo founder?

Start by defining your knowledge base: the decisions you have made, the constraints you operate within, the brand voice you want to maintain. Then deploy agents in the domain where manual work costs you the most. Connect domains as you add them, ensuring agents share context. Build the feedback loop so every task generates a learning that improves the next one. The goal is an AI organization that compounds — not a set of tools performing the same function at the same level indefinitely.

Soleur vs. Cursor: When an AI Coding Tool Becomes an Agent Platform

2026-03-19T00:00:00Z

On March 5, 2026, Cursor shipped Automations — event-driven agents that run in cloud sandboxes, trigger on GitHub PRs, Slack messages, Linear issues, and cron schedules, and learn from past runs to improve over time. Two weeks earlier, it launched a Marketplace with a curated set of engineering-domain plugins, then expanded to 30+ new plugins on March 11, 2026. Cursor is no longer just an AI code editor. It is an agent platform.

That changes the comparison. "Cursor is for coding, Soleur runs the whole company" was accurate in 2025. In March 2026, it requires a more precise examination: what Cursor's agent platform actually covers, where its scope ends, and where Soleur's Company-as-a-Service architecture begins.

What Each Platform Is

Cursor is an AI code editor built by Anysphere (CEO: Michael Truell). Its agent capabilities now span from Tab (next-token and diff prediction using Cursor's proprietary model) to Cloud Agents that run in isolated virtual machines with computer use capabilities — navigating browser UIs, running tests, and submitting merge-ready pull requests with video and screenshot artifacts. In February 2026, Cursor reported that more than 30% of PRs merged at Cursor are now created by agents operating autonomously in cloud sandboxes.

The Automations layer — launched March 5, 2026 — adds event-driven execution. Agents fire on triggers, complete engineering tasks, and loop humans in only for high-risk findings. The Marketplace — launched February 17, 2026 and expanded to 30+ new plugins in March — packages MCP servers, subagents, hooks, and rules into single-install plugins covering infrastructure (AWS, Cloudflare, Vercel), data (Snowflake, Databricks), project management (Atlassian, Linear), and observability (Datadog).

Cursor's annualized revenue reportedly exceeded $2 billion in February 2026, doubling in three months.

Soleur is a Company-as-a-Service platform. It deploys 66 agents across 8 business departments — engineering, marketing, legal, finance, operations, product, sales, and support — with a compounding knowledge base that accumulates institutional memory across every session and every domain. It runs inside Claude Code, accessed from the terminal.

Where They Differ

Domain Coverage

This is where the comparison becomes precise.

Cursor's Automations, Marketplace plugins, and Cloud Agents are engineering-domain instruments. The trigger events are GitHub PRs, Linear issues, PagerDuty incidents, and Slack messages about code. The Marketplace plugins cover the engineering toolchain: AWS, Vercel, Stripe, Databricks, Snowflake. A Cursor automation reviews a PR for security vulnerabilities. A cloud agent refactors a module and opens a merge-ready PR. These are high-value engineering workflows.

The 70% of running a company that is not engineering — marketing campaigns, legal reviews, investor reports, competitive intelligence, sales pipeline analysis, brand voice, financial planning — falls entirely outside Cursor's scope. The Marketplace has no marketing plugin, no legal plugin, no finance plugin, no sales plugin. Automations have no trigger model for a campaign launch, a contract review request, or a quarterly board report.

Soleur covers all eight departments with specialist agents at each lifecycle stage. A marketing campaign, a legal review, a competitive intelligence scan, and an engineering feature all run through the same brainstorm-plan-implement-review-compound lifecycle, with domain-specialist agents at every step.

If you are a solo founder, you are not only a developer. Cursor handles the development work exceptionally well. Soleur handles the company.

Knowledge Architecture

Cursor's Automations include a memory tool. Per the Cursor Automations documentation, "Agents also have access to a memory tool that lets them learn from past runs and improve with repetition." Rules persist instructions to a project, user, or team across sessions. An automation that ran last week carries context into this week's run.

But the memory is automation-scoped. The PR review automation's accumulated knowledge does not inform the deployment automation. The coding agent's context does not flow into anything outside the engineering domain — because everything outside the engineering domain is outside Cursor's scope.

Soleur's compounding knowledge base is cross-domain by architecture. The brand guide written by the brand-architect agent informs every piece of marketing copy the copywriter agent generates. The competitive intelligence scan updates the sales battlecards. The legal compliance agent references the privacy policy when engineering ships a new data feature. The knowledge base is a git-tracked directory of Markdown files — readable, auditable, and editable by the founder directly — that accumulates across every session in every domain.

The first time the competitive intelligence agent runs, it builds a baseline. The twentieth time, it compares against nineteen prior scans, highlights new entrants, flags shifted pricing, and updates downstream artifacts. The compounding is not a marketing claim. It is a structural property of how the knowledge base is written and read.

Automation-scoped memory and a cross-domain compounding knowledge base serve different goals. The first improves repeated engineering tasks. The second builds organizational intelligence.

Workflow Orchestration

Cursor Automations execute engineering tasks: review this PR, fix this incident, run this linter on schedule. The workflow is task-scoped: one trigger, one output, one notification.

Soleur runs lifecycle workflows across all eight departments. Every domain follows the same structure: brainstorm > plan > implement > review > compound. An engineering feature moves through specification, architecture review, implementation, security audit, and knowledge capture — in sequence, with the full context of every prior decision available at each stage. A marketing campaign runs through the same lifecycle with marketing-domain agents: growth strategist, copywriter, fact-checker, social distribution.

The difference between a task runner and an organizational workflow is the context that flows between steps. Cursor's Automations excel at running well-defined engineering tasks. Soleur's lifecycle workflows handle ambiguous, judgment-intensive processes across the full organizational scope.

Pricing

Cursor's pricing as of March 2026:

Hobby: Free (limited agent requests and Tab completions)
Pro: $20/month (extended agent limits, cloud agents, frontier model access)
Pro+: $60/month (3x usage credits, background agents)
Ultra: $200/month (20x usage, priority access)
Teams: $40/user/month

Soleur is open-source. The platform is free.

If you already pay for Cursor Pro at $20/month and add Soleur, you have an AI coding environment and a full eight-department AI organization for $20/month total.

When Cursor Is the Right Choice

Cursor is the best available AI coding environment. For a developer whose primary constraint is software engineering velocity — writing, reviewing, and shipping code faster — Cursor's Tab model, Cloud Agents, and Automations represent a meaningfully differentiated platform. If your company's current bottleneck is the engineering backlog, Cursor directly addresses it.

Soleur does not replace Cursor. If Cursor is your coding environment of choice, continue using it. Soleur operates at the organizational layer, not the IDE layer.

When Soleur Is the Right Choice

Soleur is the right choice when the bottleneck is not engineering alone.

Solo founders do not spend 100% of their time writing code. They spend time on competitive positioning, legal review, financial planning, customer communications, marketing, and sales — domains where no Cursor automation fires and no Marketplace plugin ships. Soleur covers those domains with the same structured lifecycle, the same compounding knowledge base, and the same principle: you make the decisions, agents execute, knowledge compounds.

The distinction is organizational scope. Cursor builds the product. Soleur runs the company.

FAQ

Q: Does Soleur work with Cursor?

Yes. Soleur runs inside Claude Code; Cursor is an IDE. They operate at different layers of the stack. You can use Cursor for writing and reviewing code while using Soleur for the organizational workflows — marketing, legal, finance, operations, product, sales — that happen outside the IDE. There is no conflict.

Q: Cursor Automations now include memory. Is that equivalent to Soleur's knowledge base?

No. Cursor's automation memory is scoped to individual automations within the engineering domain. An automation that learns from past PR reviews does not share that knowledge with your marketing campaigns or legal reviews. Soleur's compounding knowledge base is cross-domain: the brand guide informs marketing copy, competitive intelligence updates sales battlecards, and legal decisions flow into engineering constraints automatically.

Q: Is Cursor's Marketplace a competitor to Soleur's agent ecosystem?

Cursor's Marketplace covers the engineering toolchain: infrastructure, data, observability, project management. It has no marketing, legal, finance, or sales plugins. Soleur's 66 agents cover all eight business departments. They address different scopes, not the same one.

Q: Does Cursor's $2B+ ARR indicate it is better for enterprise use than Soleur?

Revenue scale reflects adoption within a specific domain — engineering teams at large organizations. Soleur is open-source and auditable: every agent prompt, every skill, every knowledge-base schema is readable. Founders who need full transparency into what their AI organization is doing can read the source. The two products serve different organizational scopes and are not direct enterprise-vs-startup substitutes.

Soleur vs. Notion Custom Agents: Company-as-a-Service vs. Workspace Automation

2026-03-17T00:00:00Z

Notion passed 100 million users in August 2024, and a workspace that stores everything about how a company operates. On February 24, 2026, it shipped Custom Agents — autonomous AI teammates that automate recurring work across Notion, Slack, Mail, Calendar, and integrated tools. For a solo founder already living in Notion, the pitch writes itself.

The question is what Notion Custom Agents actually automate, and whether that overlaps with what Soleur provides as a Company-as-a-Service platform.

What Each Platform Is

Notion Custom Agents are autonomous AI teammates that run inside your Notion workspace, launched with Notion 3.3 on February 24, 2026. They operate on triggers — schedules, Slack messages, database changes, email arrivals — and execute tasks without prompting. Notion built three primary workflows: Q&A agents that answer recurring questions from your knowledge base, task routing agents that capture and assign incoming work, and status update agents that compile progress reports. Integrations include Slack, Notion Mail, Calendar, Figma, Linear, HubSpot, and custom MCP servers. Available on Business ($20/seat/month) and Enterprise plans, currently in free beta through May 3, 2026, then transitioning to a credit-based model at $10 per 1,000 Notion credits.

Within the beta, early testers had built over 21,000 agents; Notion itself runs 2,800 agents internally.

Soleur is an open-source Company-as-a-Service platform. It deploys 66 agents across 8 business departments — engineering, marketing, legal, finance, operations, product, sales, and support — with a compounding knowledge base that accumulates institutional memory across every session and every domain. Soleur is designed for the terminal, running inside Claude Code, with a workflow lifecycle that runs from brainstorm through planning, implementation, review, and knowledge capture.

Where They Differ

The surface area overlaps until you look at the architecture.

What Gets Automated

Notion Custom Agents automate recurring, predictable tasks: triage incoming requests, compile weekly status reports, answer repeated questions from a knowledge base, route tasks to the right team member. The trigger model — schedule, database change, Slack message — is well-suited to repetitive operational work that needs no judgment variation.

Soleur orchestrates complete business processes that require domain judgment. An engineering feature moves through specification, architecture review, implementation, security audit, and knowledge capture. A marketing campaign runs the same structured lifecycle with marketing-domain agents at every stage. A legal review from the compliance agent references the privacy policy automatically. These are not scheduled tasks — they are judgment-intensive workflows that require cross-domain context at every step.

Both platforms automate work. The work they automate is categorically different.

Knowledge Architecture

Notion agents draw context from your Notion workspace: pages, databases, connected apps. That context is rich. If you have built a thorough Notion workspace, the agents have access to your SOPs, project databases, meeting notes, and CRM data. But that context is workspace-scoped: it reflects what you have put into Notion, in the structure Notion uses. The marketing agent and the engineering agent both read from the same workspace, but one domain's decisions do not automatically inform the other domain's workflows.

Soleur's compounding knowledge base is built from cross-domain learning. The brand guide informs every marketing artifact. The competitive intelligence scan updates the sales battlecards. The legal compliance agent references the privacy policy when engineering ships a new data feature. Every session writes back to the knowledge base — not just logs, but structured institutional memory. The 100th session is not just a day older than the first. It is categorically more capable.

Workspace context and compounding knowledge are different things. The first reflects what exists. The second reflects what was decided, why, and what it means for everything else.

Workflow Depth

Notion agents are excellent at running defined tasks on schedule. Write a daily standup summary. Triage Slack messages into a database. Send a weekly report. These are high-value workflows for teams managing operational overhead.

Soleur runs lifecycle workflows across 8 business domains. The brainstorm-plan-implement-review-compound cycle applies from engineering PRs to marketing campaigns to legal reviews. Each domain has specialist agents that bring deep domain judgment to every step. A security review does not run once per sprint on a schedule — it runs as part of the implementation lifecycle, with access to the full context of what changed and why.

Notion is a platform for teams managing recurring operations. Soleur is a platform for one founder managing an entire company.

Team Architecture vs. Solo Founder Architecture

Notion Custom Agents are built for teams. They are created, shared, and managed collaboratively, with enterprise-grade permission controls, usage analytics, and version control. The architecture assumes distributed ownership of workflows.

Soleur assumes one decision-maker. The solo founder owns every architectural decision, every campaign, every compliance choice. The system executes. Every agent produces output for the founder's review. The knowledge base compounds the founder's judgment, not a committee's. The architecture is not a limitation — it is a design choice. When there is one decision-maker, every agent can be fully aligned with that person's context.

Pricing

Notion Custom Agents are currently in free beta through May 3, 2026. From May 4, they run on Notion credits: $10 per 1,000 credits, usage-based by task complexity. Custom Agents require a Business plan at $20 per seat per month or an Enterprise subscription.

Soleur is free and open-source under the Apache-2.0 license. A paid tier is planned but not yet released. The full codebase is public and auditable.

The cost comparison depends on what you are replacing. Notion charges for the seat plus credits at scale. Soleur's institutional knowledge lives in your repository, under your control, with no per-session cost accumulating against task volume.

Terminal vs. Workspace

Notion agents run inside Notion. Their value compounds inside the Notion workspace and the tools it connects to. If your workflow centers on Notion — your projects live there, your team communicates there, your data is organized there — Custom Agents operate on familiar ground.

Soleur is terminal-first. It runs inside Claude Code, in the same environment where engineering decisions get made, where code gets shipped, where technical context lives natively. The marketing copywriter reads the brand guide from the repository. The architecture review happens in the same session as the implementation. The knowledge base is a git-tracked directory — version-controlled, diffable, transferable.

For a solo founder who ships code and runs a company from the terminal, Soleur's surface is the surface where work already happens.

Side-by-Side Comparison

Dimension	Notion Custom Agents	Soleur
Primary use case	Automate recurring workspace tasks: triage, standups, status reports	Orchestrate full business lifecycle: engineering, marketing, legal, finance, ops, product, sales, support
Knowledge architecture	Workspace-scoped: Notion pages, databases, connected apps	Cross-domain compounding: grows across every session and every domain
Workflow model	Trigger-based (schedule, Slack, database change)	Lifecycle-based (brainstorm → plan → implement → review → compound)
Integrations	Slack, Mail, Calendar, Figma, Linear, HubSpot, MCP servers	MCP ecosystem via Claude Code; compounding knowledge base replaces integration-driven context
Target user	Teams managing shared recurring operations	Solo founders running a full company
Pricing	Free beta until May 3, 2026; $10/1,000 Notion credits + Business plan ($20/seat/month)	Free (open-source, Apache-2.0). Paid tier planned.
Open source	Proprietary	Apache-2.0. Full source code public.
Interface	Web and desktop (Notion workspace)	Terminal (Claude Code)
Cross-domain coherence	Workspace context shared; domain decisions not cross-referenced automatically	Every domain reads from and writes to the same compounding knowledge base
Current availability	Free beta (Business and Enterprise plans)	Live (open source)

Who Each Platform Is For

Notion Custom Agents are the right choice if:

Your workflow is centered in Notion — projects, data, and team communication all live there
You need to automate recurring operational tasks: triage, standups, status reports, task routing
You manage a team and need shared agents with collaborative ownership
Your integrations are Slack, Figma, Linear, or HubSpot and you want AI running on top of them
You want zero installation overhead on top of your existing Notion subscription

Soleur is the right choice if:

You work in the terminal via Claude Code
You need cross-domain coherence — marketing that references legal decisions, engineering that reflects competitive intelligence, finance that tracks what product decided
You need institutional memory that compounds across sessions, not workspace context that refreshes
You are building a company, not managing a team's recurring operations
You care about open-source transparency: auditable agents, modifiable workflows, your knowledge on your machine

The Compounding Difference

Notion Custom Agents are effective at what they were designed for. A founder using Notion to automate standups and task triage saves real hours every week. Those hours are valuable. They are not compounding.

A founder using Soleur for six months has built an AI organization that knows how the company thinks. The brand positioning from the marketing agent informed the investor memo. The architecture decision from last sprint is referenced in the compliance review. The competitive intelligence from three weeks ago shaped the pricing strategy. None of this required the founder to copy information between sessions. The knowledge accumulated.

Workflow automation removes repetitive work. Compound knowledge removes repetitive thinking. Both matter. One scales linearly with the tasks automated. The other scales exponentially with the decisions accumulated.

That is the difference between a workspace with smart automation and a company-as-a-service platform.

Start Building

Soleur runs 66 agents across 8 departments with a compounding knowledge base that gets more powerful every day you use it. Open source, terminal-first, built by a solo founder using the platform itself.

claude plugin install soleur

Explore the 66 agents, read what company-as-a-service means for solo founders, or get started in five minutes.

Frequently Asked Questions

Can Notion Custom Agents replace Soleur for a solo founder?

Notion Custom Agents automate recurring operational tasks within the Notion workspace — standups, triage, status reports. Soleur orchestrates complete business lifecycle workflows across 8 domains with a compounding knowledge base. They automate different categories of work. A solo founder building a company will find Soleur covers territory Notion Custom Agents are not designed for: cross-domain knowledge compounding, engineering lifecycle management, security reviews, and competitive intelligence workflows.

What is the pricing difference between Notion Custom Agents and Soleur?

Notion Custom Agents are free through May 3, 2026. From May 4, they require a Business plan ($20/seat/month) plus Notion credits ($10 per 1,000 credits). Soleur is free and open-source under the Apache-2.0 license — no per-seat cost, no credit system. A paid hosted tier is planned but has not launched.

Does Notion have a compounding knowledge base like Soleur?

Notion agents draw context from your Notion workspace — pages, databases, and connected applications. That context is workspace-scoped: rich within Notion, but decisions made in one domain do not automatically inform workflows in another domain. Soleur's compounding knowledge base grows across every session and every domain: the brand guide informs marketing copy, competitive intelligence informs pricing strategy, legal decisions inform engineering constraints. The architecture is different in kind, not just in degree.

How does Notion Custom Agents pricing work after the free beta ends?

Starting May 4, 2026, Notion Custom Agents move from free beta to a credit-based model. Each agent run uses Notion credits based on task complexity. Credits are priced at $10 per 1,000 Notion credits and are shared across the workspace, resetting monthly. Unused credits do not roll over. Custom Agents require a Business plan ($20/seat/month) or an Enterprise plan.

Is Soleur available inside Notion?

No. Soleur is a terminal-first platform that runs inside Claude Code. It does not operate within the Notion workspace. If your workflow centers on Notion for team collaboration and recurring task automation, Notion Custom Agents are built for that surface. If your workflow centers on the terminal and requires cross-domain AI organization with compounding knowledge, Soleur provides what Notion Custom Agents are not designed to offer.

Soleur vs. Anthropic Cowork: Which AI Agent Platform Is Right for Solo Founders?

2026-03-16T00:00:00Z

Anthropic Cowork offers a plugin for HR, one for engineering, one for financial analysis, and seven more besides. On paper, it covers the same organizational territory as Soleur. On examination, the architectures are different enough that the comparison determines which platform belongs in a serious founder's stack.

This article examines both platforms on the dimensions that matter: knowledge architecture, cross-domain coherence, workflow depth, pricing, and openness. The goal is an honest comparison.

What Each Platform Is

Anthropic Cowork is Anthropic's AI work product, offering 10 department-specific plugin categories built into the Claude interface: HR, Design, Engineering, Operations, Financial Analysis, Investment Banking, Equity Research, Private Equity, Wealth Management, and Brand Voice. Enterprise connectors include Google Workspace, DocuSign, Apollo, FactSet, LegalZoom, Harvey, Slack, and others. Cowork is included with every Claude subscription — Pro, Team, and Enterprise.

In March 2026, Anthropic's Cowork technology expanded into Microsoft 365. Microsoft launched Copilot Cowork on March 9, 2026, in close collaboration with Anthropic, bringing Claude's Cowork capabilities into Outlook, Teams, and Excel. It is currently in Research Preview, with broader availability planned for late March through the Microsoft Frontier program.

Where They Differ

The capability list overlaps until you examine the architecture.

Knowledge Architecture

Cowork plugins do not share a cross-domain knowledge base. The marketing plugin that wrote your brand positioning last week starts fresh today — it does not remember what was decided. Each plugin operates independently with no persistent memory that compounds across sessions or domains. You carry the context manually.

Soleur's compounding knowledge base persists and accumulates across every session. The brand guide informs every piece of marketing copy. Competitive analysis updates pricing strategy. Legal decisions flow into engineering constraints. The 100th session is dramatically more productive than the first — not because the models improve, but because the institutional knowledge compounds.

Microsoft Copilot Cowork moves the bar by adding Work IQ — intelligence drawn from a user's emails, files, meetings, and chats across Microsoft 365. It is a meaningful improvement over isolated task invocation. But it is workspace context, not a compounding cross-domain knowledge base. The next campaign does not know what was decided in the last architecture review. The legal audit does not automatically reference the product roadmap.

This is the structural distinction. It is not a feature gap. It is an architectural difference in what knowledge means.

Cross-Domain Coherence

Cowork's 10 plugin categories operate in silos. The engineering plugin does not read what the legal plugin produced. The Brand Voice plugin's output does not automatically feed the Financial Analysis plugin's reports. Connecting output from one domain to another requires the founder to carry the context manually between plugins.

Soleur's 66 agents share a unified knowledge base. The marketing copywriter agent reads the brand guide before generating content. The competitive intelligence agent's findings shape the sales battlecards. The legal compliance agent references the privacy policy when engineering ships a new data feature. Context flows across domains automatically because every agent reads from and writes to the same compounding knowledge base.

The difference between a collection of specialists and an organization is coordination. Soleur provides the coordination layer. Cowork does not.

Workflow Orchestration

Cowork executes individual tasks. Invoke a plugin, provide context, receive output. Multi-step workflows require manual chaining — copy findings from one plugin, provide them as context to the next, maintain consistency yourself across the chain.

Soleur orchestrates complete business processes through structured lifecycle workflows. The brainstorm-plan-implement-review-compound lifecycle runs across every domain. An engineering feature moves through specification, architecture review, implementation, security review, and knowledge capture — in sequence, with full domain context at each stage. A marketing campaign runs through the same structured lifecycle with marketing-domain agents at each step.

Microsoft Copilot Cowork adds multi-step plan execution within M365 — users describe intent, Cowork builds a plan and executes it across Outlook, Teams, and Excel. That is a genuine capability advance. The scope remains M365 workflows. The lifecycle management, cross-domain orchestration, and compounding memory that define Soleur's approach do not have an analog in Cowork's current architecture.

Pricing

Cowork is bundled with every Claude subscription. Claude Pro runs $20/month, Team at $25/seat/month with an annual commitment. If you already pay for Claude Pro, you already have Cowork. That value proposition is real.

Soleur's open-source core is free — Apache-2.0 licensed. Every agent, every skill, every line of code is public and inspectable. A paid tier for hosted features is planned but not yet released.

The cost comparison is not only monetary. If your operational context lives in Cowork's session-scoped memory, it exists only while that session is open. Soleur's institutional knowledge compounds in your repository, under your control, indefinitely. The knowledge you build using Soleur is yours — version-controlled, transferable, auditable.

Microsoft Copilot Cowork carries an additional license at $30/user/month on top of Microsoft 365. The M365 E7 bundle, which packages Copilot, Entra Suite, and Agent 365, is priced at $99/user/month and available from May 2026.

Openness

Cowork is proprietary. Anthropic offers plugin templates on GitHub, but the core platform is closed. You cannot inspect how agents make decisions, audit what data is retained, or modify the platform's behaviors.

Soleur is Apache-2.0 open source. The full codebase is public. Every agent's instructions, every skill's workflow, every guardrail's logic is readable and modifiable. The platform was designed, built, and shipped using itself — every PR reviewed, every feature compounded back into the system that built it.

Side-by-Side Comparison

Dimension	Anthropic Cowork	Microsoft Copilot Cowork	Soleur
Cross-domain knowledge base	None. Plugins are siloed.	Work IQ: workspace context from emails, files, chats.	Compounding. Grows across every session and every domain.
Domains covered	10 categories: HR, Design, Engineering, Ops, Finance (IB, ER, PE, WM), Brand Voice	Microsoft 365 applications: Outlook, Teams, Excel	8 departments: Engineering, Marketing, Legal, Finance, Operations, Product, Sales, Support
Workflow orchestration	Individual task invocation	Multi-step M365 task execution	Lifecycle workflows (brainstorm → plan → implement → review → compound)
Pricing	Included with Claude Pro ($20/mo), Team ($25/seat/mo annual)	$30/user/month add-on; M365 E7 bundle $99/user/month	Free (open source). Paid tier planned.
Open source	Proprietary	Proprietary	Apache-2.0. Full source code.
Terminal / Claude Code integration	Not applicable — web/desktop interface	Not applicable — Microsoft 365 surface	Native — runs inside Claude Code terminal workflow
Enterprise connectors	Google Workspace, DocuSign, Apollo, FactSet, LegalZoom, Harvey, Slack	Microsoft 365 native (Outlook, Teams, Excel, SharePoint)	MCP ecosystem via Claude Code
Current availability	Live (Pro, Team, Enterprise plans)	Research Preview (late March 2026 Frontier program)	Live (open source)

Who Each Platform Is For

Anthropic Cowork is the right choice if:

You use Claude primarily through the web or desktop interface
You need enterprise connectors built in — Google Workspace, DocuSign, FactSet, LegalZoom
You want investment banking, equity research, or private equity domain coverage
You want zero installation overhead — it is already in your Claude subscription

Microsoft Copilot Cowork is the right choice if:

Your workflow centers on Microsoft 365 — Outlook, Teams, Excel, SharePoint
You need enterprise data protection within your M365 tenant
Your organization is already on Microsoft 365 Business or Enterprise plans

Soleur is the right choice if:

You work in the terminal via Claude Code
You need institutional memory that compounds across sessions, not resets
You need cross-domain coherence — marketing that references legal, engineering that references compliance, finance that reflects competitive intelligence
You care about open-source transparency: auditable agents, modifiable workflows, your knowledge on your machine
You are building a company, not executing isolated tasks

The choice is not which platform lists more features. It is which architecture fits how you build.

The Compounding Advantage Over Time

The architectural difference does not show up in the first week. It dominates by month six.

A founder using Cowork for six months has executed hundreds of expert tasks. Each one was good. None of them informed the next. The brand positioning decided in the marketing plugin in January did not shape the investor memo written in the financial analysis plugin in March.

A founder using Soleur for six months has built something different: a knowledge base that encodes every architectural decision, every brand positioning choice, every competitive move, every legal precedent established across every project. That knowledge feeds every future session. The system does not just remember — it applies.

This is what compound engineering looks like at the company level. The knowledge base compounds. The agents get smarter. The system validates its own workflow. The 100th session is categorically more productive than the first.

Cowork's session-scoped model is a valid design choice for executing expert tasks. It is not a design choice for running a company.

Start Building

claude plugin install soleur

Explore the 66 agents, read what company-as-a-service means for solo founders, or get started in five minutes.

Frequently Asked Questions

Does Anthropic Cowork have a compounding knowledge base?

No. Cowork plugins operate independently without a shared cross-domain knowledge base. Each plugin executes tasks based on the context you provide in that session. Soleur's compounding knowledge base persists and grows across every session, making every future session more productive.

Is Soleur free compared to Cowork?

Cowork is bundled with Claude subscriptions — Claude Pro is $20/month. Soleur's core is free and open-source under the Apache-2.0 license. Both have free access. The difference is architecture: Cowork's knowledge is session-scoped; Soleur's compounds indefinitely in your own repository.

Can Cowork plugins share context with each other?

No. Cowork's 10 plugin categories are siloed — the engineering plugin does not read what the legal plugin produced, and the Brand Voice plugin's output does not automatically inform other plugins. Soleur's agents share a unified knowledge base so decisions in one domain inform every other domain.

What is Microsoft Copilot Cowork?

Microsoft Copilot Cowork is a collaboration between Microsoft and Anthropic that brings Claude's Cowork capabilities into Microsoft 365 — Outlook, Teams, and Excel. Launched in Research Preview on March 9, 2026, it enables multi-step background task execution within M365 applications. Broader availability is planned for late March 2026 through the Microsoft Frontier program.

Does Soleur integrate with Microsoft 365?

Soleur is a terminal-first platform running inside Claude Code. It does not integrate directly with Microsoft 365 applications. If your workflow centers on M365, Microsoft Copilot Cowork is the right choice for that surface. If your workflow centers on the terminal and Claude Code, Soleur provides the cross-domain depth and compounding knowledge that M365 integration does not offer.