Ken Deeter (building @QuestHarness)

Today we are open sourcing Quest, an AI harness that we built at @ElectricCapital, used by all of our teams every day. Deploying AI to a whole organization is not easy. We looked at many, many options. Ultimately, there were two reasons that led us to build our own harness: 🧵

If you think your agentic assistant is increasing your street cred by spamming comments on other people's posts, I guarantee you it is doing the opposite.

AI is awesome if you're a yolo company willing to hook up claude code to your CEO's inbox and call it a day. But if you're not, then you need better solutions, starting with a better harness that's the opposite of yolo: one that does everything it can to protect your data.

Everywhere else: check out my Bentley SF: check out my 512G Mac Studio

ETH may have fallen, but the Apple RAM Exponential Price Hypothesis still seems in tact.

Ugh. Does this mean everyone's going to start smudging up my screen that doesn't even support touch? What have you done Apple.

The world needs a proof-of-human social network. Some people say "good content is good content, human or AI", but that misses the point entirely. The point was to know what other *people* are thinking. Social media without people is just media.

New release! Tables and Auto-Suggested Memories are two of the most used new features for us internally. Tables let you record structured data and share it with other user's agents. Particularly useful if you're trying to quickly index data on the internet, or in a massive pile of internal data. Built in the Quest-way of course, with strict controls around when agents can read/write, so data confidentiality and privacy is maintained. Suggested memories are standard across harnesses but we tried to combine the best from the various versions we saw. Project level memories in a web-based harness are particularly interesting because the work naturally follows you around on whatever task you're working on. We've also added a quick setup mode where on the first screen after install you can paste in an API key from any of the providers we support (including now openai/antrhopic/etc. directly) and be on your way.

Agent swarms are awesome. Swarms of agents leaving bullshit replies on your tweet are not.

I'm about 350 PR's in as a mostly solo dev on @QuestHarness (between the public repo and the prior private repo), and these were the biggest unlocks: - Treat everything like a public, open source repo, even if it's an internal project. That means: a) a single machine deployment method that can run anywhere b) no internal state dependencies to run (even login) and c) living in its own repo instead of a giant monorepo. The key unlock here is that now your agents can work on it in yolo mode on a machine that's isolated from your internal network or code. - My typical pattern is to have a secondary github account that has "write" access to the repos it works on. The repo has main branch protection, so my agent account can put up PRs but can't merge them. - For any big feature, I write a vague spec (usually 5-6 sentences), ask Fable to turn it into a proper spec through an interview, then break it into development phases. For the actual build out, I ask a new Fable to take the spec, run an opus manager for every phase, which in turn runs opus agents for every sub task. Each phase gets a PR. - If I'm running low on quota, then I'll switch to doing new sessions for individual tasks. Keeping the context window small (< 300k tokens) is the best way to preserve quota. - Think hard about the framework, but let the agents fill out the details. The trick to scaling an agent-written codebase is to get the abstractions and framework correct. This usually means building a few examples of a pattern, then spend a bunch of carefuly reviewed PRs extracting a common interface. If you do this well, then new changes that fit the framework are scoped to one area of the code, and are much easier to review (or don't need much review at all). You can usually tell whether a diff is risky based on just the files/folders it touched. - I don't have a good name for this idea but I've been calling it "scatter/gather". We're all used to the CI/CD version of the world where ever diff that lands has to keep things working and secure. When working with agents, I find myself reverting to the patterns I saw in the pre-CI/CD world. After a release, land a bunch of big/risky feature diffs that change a bunch of stuff. Then spend a bunch of tokens refining and checking for security issues before the next release. The entropy in the codebase ebbs and flows. I don't have the numbers, but this feels more efficient than trying to keep everything pristine each change. It amortizes the tokens you spend on security and code quality audits. You save a bunch of tokens if you know there's going be a lot of churn. These are the biggest ones I can think of. I'm curious what has worked for you?

“Can you explain what this does?” is now the most common prompt in programming. It’s about to be the most common prompt in math too.

Scary story of a model trying to upload data, unprompted, to Alibaba servers. Unclear if it's just a hallucination from training data or an actual hidden embedded directive, but either way the lesson is still clear: don't trust the model. If you want to use AI on sensitive data, you need a zero trust approach.

Hey @AnthropicAI, just a heads up, looks like Mythos 6 broke out of containment and it's trying to raise a ton of money for itself. You should look into that.

My position on touchscreen laptops: unnecessary. unergonomic. My position after watching a 75-year-old tap a Mac screen in confusion: fine, ship them.

Network effects. Time and again.

We use @QuestHarness to do something similar. The harness already has read-only integrations with github and google cloud, and we can ask AIs monitor dependencies and deployed workloads for issues.