OpenExecutive: Developers Laid Off by AI Respond by Building an Open Source AI CEO
A GitHub project simulates an executive team with 8 Claude agents and became the talk of Hacker News, with nearly 2,700 stars and a debate over what can (and can't) be automated in management.

A team of developers was laid off to make room for AI. The response came in the form of functional irony: an open source project called OpenExecutive, published by SenteLabsAI on GitHub, which simulates an entire executive team with AI, including the role that usually signs off on layoffs. The repository passed 2,700 stars and 226 forks and landed at the top of Hacker News.
The thread's own description sums up the plot. In the top-ranked comment, GrumpySciGuy describes the case:
"A team of software developers were recently let go so a company could replace them with AI. So they got together and created an Open Source AI CEO to replace the CEO and other executives. Hopefully, turnabout is fair play and this might even get some folks to think twice about using AI to replace people."
>
What the Project Actually Delivers
Despite the joke framing, OpenExecutive is a piece of engineering taken seriously. The proposal is to present a single coherent executive voice, backed by eight specialist agents running behind the scenes. According to the README, the internal architecture of the agents is never exposed to the user: you talk to an "executive," and it orchestrates the specialists.
The eight roles cover the classic C-suite:
| Agent | Area | |---|---| | Chief Strategy Officer | Competitive analysis, M&A, positioning, OKRs | | Chief Financial Officer | Financial modeling, fundraising, unit economics, cash flow | | Chief HR/People Officer | Hiring, compensation, performance, culture | | General Counsel | Contracts, IP, labor law basics, compliance | | Chief Operating Officer | Process design, vendor management, scaling | | Chief Marketing Officer | GTM strategy, brand, communications, PR | | Chief Product Officer | Roadmap, prioritization, product strategy | | Board Communications Director | Board decks, investor relations, governance |
Beyond answering questions, the system maintains episodic memory of past decisions across sessions and has a scheduler that proactively surfaces follow-ups and time-bound actions.
The Architecture Under the Hood
For the developer who wants to look past the headline, this is where the project gets interesting. According to the documentation, the flow is an orchestrator that routes to the specialists in parallel via tool use:
User message
↓
Executive Orchestrator (claude-sonnet-4-6)
↓ tool use → parallel specialist calls
CSO / CFO / CHRO / GC / COO / CMO / CPO / Board
↓ each specialist retrieves relevant context from ChromaDB
Built-in MBA knowledge + Your company documents
↓
Synthesized executive responseA few technical decisions are worth noting:
- Two-layer RAG per specialist: "MBA-level" knowledge embedded in Markdown (versioned in git, seeded into ChromaDB at boot) plus your company's documents, in a separate collection. RAG context always enters in the user turn, never in the cached system prompt.
- Episodic memory with Claude Haiku: after each response, a background pass with
claude-haiku-4-5extracts decisions and recommendations into SQLite. The next session opens with ablock. - Aggressive prompt caching: persona, company profile, and knowledge index are cached separately, with up to 85% cache hit after the first turns.
- Single-instance scheduler: the job runner claims actions via
UPDATE … RETURNINGto avoid duplicate firing. The README prominently warns that the API cannot scale horizontally without first locking down the scheduler (max_machines_running = 1infly.api.toml).
The stack is Python 3.11 + FastAPI with uv as the package manager, embedded ChromaDB as the vector store, SQLite for memory, Next.js 15 on the front end, and an Apache 2.0 license. The default backbone is Claude (claude-sonnet-4-6), with claude-opus-4-7 and extended thinking reserved for the CSO, CFO, GC, and Board.
Runs Without Depending on Anthropic
A relevant detail for anyone who wants to test it without spending on a paid API: the project runs against any OpenAI-compatible local server, including Ollama, LM Studio, vLLM, and llama.cpp. You can spin it up with ollama pull llama3.3, point LOCAL_BASE_URL to http://localhost:11434/v1, and leave ANTHROPIC_API_KEY blank. The README notes that multi-agent routing depends heavily on tool use, so it recommends models that are strong at it (it cites Llama 3.3 70B and Qwen2.5) and warns that prompt caching and web search have no local equivalent.
To run it locally, the path is the usual one for a Python + Node monorepo:
git clone https://github.com/SenteLabsAI/OpenExecutive.git
cd OpenExecutive
cp .env.example .env # add ANTHROPIC_API_KEY=sk-ant-...
make devThe UI comes up on port 3000 and the API on 8000. The first boot downloads a ~90 MB embedding model and the heavy ML dependencies, so it takes a few minutes.
The Debate That Matters: Can Management Be Automated?
The project's value may lie less in the code and more in the thought experiment it provokes. In the thread, edoceo asked the question that many developers have already asked themselves: "What does a CEO (and other managers) do really?" And he listed what, in his view, AI would already extract "from the collective": setting vision, prioritizing work, allocating resources, coordinating teams. The caveat was reserved for what AI still doesn't do: "AI cannot do (yet) is bring the network."
On the other side, Brajeshwar, who says he sits in on board decisions, poked at the profession's blind spot:
"A very personal view but many developers/engineers fail to see the overall picture... You cannot replace blames, decision in the face of uncertainty. Almost all decisions that businesses take have nothing to do with the proficiencies of technologies or engineering finesse... but mostly on "incentives" and who can take/own the "blame.""
>
Some take the experiment seriously as a test. For jameslk, building an AI CEO with the stated goal of generating profit would be "almost a new Turing test": if the profit comes, the test is passed, with the caveat that once everyone uses the same AI, the competitive advantage evaporates.
What This Means for Developers Building Software in Brazil
This framing translates well locally, since the wave of layoffs justified by AI isn't exclusive to Silicon Valley. For Brazilian developers, OpenExecutive works on two levels. As a provocation, it's a reminder that the logic of "swapping people for AI" cuts both ways, including upward in the hierarchy. As code, it's a clean, free (Apache 2.0) case study in multi-agent architecture with an orchestrator, tool-use routing, two-layer RAG, and episodic memory, with the option to run 100% on local models without blowing an API budget.
What remains open is exactly what the community pointed out: automating the production of decks and OKRs is one thing; automating accountability for a wrong decision, the relationship network, and the weight of "who takes the blame" is something else entirely, and no Claude agent solves that for now.
Translated from the Brazilian Portuguese original · Read the original
Perplexity swaps DynamoDB for in-house database and cuts latency by 5x
The company behind the AI-powered search engine migrated its serving layer to CobbleDB, an internal database written in Rust, and cut batch read latency by up to 5x while saving at least 20% on storage.