A simple AI agent that helps users click a few buttons shouldn't cost $0.50 per conversation. And building it shouldn't require some of the best engineering work I've done in my 10-year career. But it did. And the experience completely changed how I think about the future of software.
Building an agent from first principles
A few months ago I built an AI agent from scratch for a hackathon project at my previous company. I made a deliberate choice: no LangChain, no OpenAI Agents SDK, no plugins, no frameworks. I wanted to understand the real challenges of building agents from first principles. And honestly, I had to. The surrounding application was security-conscious and rigid in its architecture. I needed full control over the point of inference, tool passing, conversation data... all of it.
I built the whole thing into our Django app. I was wrangling with the AWS Converse API, managing my own context window, building tools based on existing internal endpoints and service functions, and validating every tool input and output directly with Pydantic. I hand-rolled all the agent harness stuff that sounds straightforward until you actually have to do it.
The trickiest part was figuring out how to get a natively async experience (a back-and-forth conversation with an LLM) to work inside a fundamentally synchronous Django web app. I built the central orchestrator in an async worker task and used websockets, Redis pub/sub, Celery, RabbitMQ, and a few other things to stitch everything together. All this jujitsu was necessary to repurpose our existing synchronous endpoints as tools without rewriting them. It was honestly remarkable that I got it all working without spinning up new infrastructure. Asyncifying a synchronous backbone required a level of creativity I hadn't needed in years, and I loved every minute of it.
The cost reality check
Then came the part that really opened my eyes.
We built a pretty modest agent by 2026 standards. Simple back-and-forth conversations to help users click buttons, fill out fields, build reports, etc. Conversations with even these basic interactions were adding up fast on AWS GovCloud. We ran the numbers: scaled to just four conversations per day across our user base, it would have literally doubled our existing AWS budget. I was wicked excited to build some momentum for agents within the company, and this cost reality check really took the wind out of my sails.
I did not have time to dig into the context management problem before I left. I'm confident I could have reduced costs significantly by being more clever with the context, optimizing tool call responses, introducing subagents, etc. But all those ideas would have been experiments, at best. That was the hardest part. Keeping the context efficient and the costs reasonable felt like an art project with no rubric.
The gap between "cool hackathon win" and "production-ready agent" was enormous, and context management was a huge chasm.
Everyone is banging their head against the same wall
When I asked around, I realized I wasn't alone. I spoke to a few other teams in Boston and SF, and many were reinventing the wheel just like I had, building their own agent harnesses and rolling their own context management from scratch. And those who used frameworks shared that they hit similar walls I did the moment their agents got beyond trivial: insane token costs, context windows blowing up, and poor agent reliability with longer conversations.
Then the subagent craze took off and things got even more complex. More agents calling more agents, each one burning through tokens with zero awareness of the others' context. I kept coming back to the same thought: there has got to be a better way.
Hand-rolling context management when building agents is equivalent to using Excel to build a core business application. You can technically do anything with it, but everything you build is fragile, expensive, and uniquely yours in the worst way possible.
Enter Subconscious
Outsourcing context engineering is the thesis behind Subconscious.
We're building Agent Engines - systems that combine a language model with an inference runtime to absorb a lot of the complexities I struggled with when building the hackathon agent. These engines manage their own context, maximizing reliability and token efficiency, while allowing builders to focus on prompts and tools instead of the harness itself.
The team here is dialed. The mission is ambitious. The approach is unique. And the problem is one I've felt in my bones. I know firsthand how hard this is, and I know how much value there is in making it dramatically easier.
I'm excited to see what we figure out on this journey. I cannot wait to create serious value for the businesses building the next generation of agents. More to come soon.
Bleed orange,
Dana
