An AI marketing platform where specialist agents write, plan and analyze from a company's own material, without leaking one customer's brand into another's.
RoleLed product, wrote most of the backend
- Team
- Entropy Labs product team
- Timeline
- 2025 to now
- Stack
- Python, FastAPI, LangGraph, LangChain, PostgreSQL, Redis, Google Cloud, Several model providers
- Source
- Private, Entropy Labs product
What came of it
- 01More than fifteen specialist agents in production, each with its own tools and guardrails
- 02First responses several times faster once retrieval ran in parallel
- 03Spend and send actions always pass through a human approval step
Obelisk is the platform we build at Entropy Labs for marketing teams. A company uploads what it already has (brand guidelines, past campaigns, product docs, analytics access) and gets a set of specialist agents that work from it: brand voice, SEO, email, paid ads, strategy and more.
I lead the product and wrote most of the backend. The agents are what people see; most of my time has gone into the code around them.
Splitting the general agent
Early Obelisk had one general agent with an enormous prompt. It wrote ad copy when asked about analytics and started research when someone wanted a one-line answer. Splitting it into specialists, each with a short prompt and a small set of tools, fixed most of that.
Running more than fifteen of them is manageable because every model and tool call passes through a shared middleware layer. It chooses the model per request, trims long conversations, caps runaway tool loops, retries only what's safe to retry, and asks a human before anything that sends or spends. I wrote about that layer in more detail in agent middleware.
Retrieval fast enough to wait for
An agent can only work from what it knows about the company, so retrieval runs before almost every answer. The first version did it in sequence: search the documents, then the saved URLs, then the company profile, then assemble. People waited a long time for the first word.
Now the independent lookups run at the same time, and a fast, cheap model rewrites the question before the search so the search returns better material. The rewrite adds a moment and saves several. Documents go through a structure-aware pipeline on the way in, so each chunk is a coherent section of the document.
Keeping one customer's brand out of another's
Obelisk is multi-tenant: organizations contain spaces, and a space is the unit of isolation. A leak in an AI product is harder to spot than a wrong row in a table. It shows up as another company's tone, or a fact from their documents, inside your draft.
So the space is enforced at every layer. The request layer checks it, every repository scopes its queries by it, and cache keys and log lines carry it. Middleware on its own would miss the one query that forgets the scope, and that query is where leaks come from.
Sessions that survive restarts
Some agent sessions run long, with research, drafts, approvals and revisions. They have to survive deploys, dropped connections and a person coming back the next morning. Conversation state is checkpointed in PostgreSQL, and every step of an agent run is recorded as an event, so a reconnecting client can replay what it missed and we can reconstruct what an agent saw when it did something odd.
If I started it again
- I'd build the control layer first. We added middleware to working agents over months, and it should have been the foundation.
- Structured logs from the first commit, with request IDs and one event per step, would have saved a lot of long debugging sessions early on.
- I'd treat prompt injection as a property of the whole system. Pattern checks on inputs and outputs catch the lazy attempts. The damage is limited by structure: agents that can only reach their own tools, a human in front of anything that sends or spends, and retrieved documents treated as data, never as instructions.
End of case study.