- LLMs are a great foundation but building your own harness is a huge undertaking, a deep rabbit hole.
- There are harnesses available as open source libraries but that’s still coupled to an environment. Where does the state persist? Like maybe I’m a Cloudflare worker and don’t even have a file system.
Agent as a service like this lets you plug in the tools it needs to be whatever kind of agent you want. But they still get to encapsulate and continue to iterate on the really deep parts of the harness that all agents need like memory and context management.
That said, my money right now is not on the offerings from OpenAI and Anthropic because they’re stuck using their own proprietary frontier models and those aren’t actually the best choice for most agents right now. A competitor who is not an LLM lab gets their pick of the market at any given moment. Like you’d want to be using GLM 5.3 Flash right now for most things agentic.
I eventually gave up on this task. It's not possible to fight OpenAI or Anthropic's engineering teams. Their reasoning models have all kinds of undocumented back door access to the base models that you'd never be able to replicate from the outside. Even if you had full access you would not have the engineering man hours or experience to keep up.
I think this Agents API thing is a step too far, but Chat Completion is too cold now. Something approximating Responses API seems like the happy medium. You still get most of the control with the only blackbox part being the reasoning loop / tokens. Building agents using the GPT5.6 family w/ Responses API feels pretty close to Star Trek computer shit to me. I thought I was being clever with my DIY contraption on top of chat completion, but it wasn't even close. I have embraced the reality that I will need to use opaque reasoning tokens to give my clients the experiences they are paying me to provide.
It is highly custom to my needs and wants, and I think every developer needs to do this. I only talk to my planner which plans, and it subs out to designer, oracle, coders, testers, and reviewers, etc. It is thus highly optimized for correctness. You can TDD or no TDD. You can fast track small changes. I tweak my harness dozens of times as I encounter new edge cases (esp when I switch models and encounter models not as good at following instructions).
As you can start to see, it is better to own the harness because nobody can build something custom that 100% fits your needs or development philosophy.
I have been running my own setup and evolving it since November as I come up with more ideas and needs. The nicest bit is not being tied to one provider or another. Anthropic decides to stop supporting Claude agent sdk with subs? Or astra outstrips other models? My harness now works with Claude/cursor/codex and soon ACP.
I might be absolutely wrong, but "harnesses" / cc-derivatives became "good enough" only maybe a year ago max. Before that, people were pushing for gigantic folder structures with custom documents and "pretend you're X" stuff.
My point is, depended on what you're trying to achieve, testing out current-gen harnesses, and nudging your workflows towards them might be better RoI, rather than chasing something that might be throwaway code a quarter later.
Obviously, this really depends on whether you believe model development will speed up or slow down in the upcoming future.
And the system prompt worked great regardless, so i don't think your main point holds, especially as models improves; it isn't throwaway code, but for sure it's evolving constantly, as my own workflow keeps changing.
> My point is, depended on what you're trying to achieve, testing out current-gen harnesses, and nudging your workflows towards them might be better RoI, rather than chasing something that might be throwaway code a quarter later.
Fair point, depends if it's an hobby or you are a developer full time, in the latter case i think it's definitively worth it.
There is the standard API that things like openRouter exposes, thats supported by every provider, and all it is, is manipulating a large blob of memory by adding your own words or asking the GPU to append new words.
Everything else around it is window dressing. All providers accept that API, (only Anthropic has blocked access on their consumer subscription tier).
Its how businesses write their 'bots'. Nobody - except the people trying to sell you "magic" - is incentivized to remove that kind of access.
I can switch out openai/anthropic/deepseek/openrouter/kimi/selfhosted at the drop of a hat. Its a big reason you'll see a comment on HN talk about "There is no moat".
Calling them cc-derivatives is wrong. I've seen many features land in other harnesses long before they came to Claude.
The only thing Claude seems to be "cheating" with is that:
- They provide Windows users a unix VM hosted on their servers - I dont want or need that
- They're better 'trained' at doing compaction / providing the illusion of continuity
- They might do automatic model-switching (not sure if they do) - not something i need.
Sure, if you're in the market for magic then dont put time in having your own harness and just accept the lock-in. Since I'm using them so much i think its worth the investment.
The capabilities of a model unlocks certain harness behaviour, and in its terms might be beneficial to automate more of your x, y, z.
I guess computer use would be an example I was thinking about. Certain models are not as good as some current models (Astra/Fable) in understanding through screenshots, or going through some hoops in some environments. As models evolve, they unlock new capabilities, that you either have to keep implementing in your harness, or using an existing one. I’m pro-using existing just because it doesn’t make sense for my org to support another dev tool internally, when there is heavy better development happening by people who focus on that.
The reason why i said cc-derivative, as far as I can see, cc was the one that convinced people “it might be a good idea to dev this way”. Sure you had some lesser known harnesses around, but a year+ ago, nobody really cared.
I don’t think, at least as of now, anything is really much of a lock in. We switch out between cc/codex/cursor and it takes trivial amount of time to set stuff up, depended on how your dev loop goes.
Again, it really depends on one’s conviction of “how fast things will develop from now on”. I personally think stuff will keep changing very fast. In a year what we think of harnesses will be different. Investing in custom tooling might be bad, as that is basically a lock-in. But again, I don’t know the future, but that’s my bet. Hovering around the edges and using what others battle test is an easy way out right now.
Also in some larger orgs, there is more friction in model choices. So you slowly start losing the benefits of model-swapping. Obviously different for personal projects.
There's a difference between their harness and your harness. The latter can be tuned to your preferences, while the former cannot. A custom harness can do everything that a packaged harness cannot. Good luck getting Claude Code to coordinate with multiple model providers or deeply integrate with your environment.
The point you're making is to be a consumer, which admittedly, is probably best for most people, but it's not going to satisfy the hacker. Normies aren't building custom harnesses, so your argument is DOA for the target demographic.
Also, vendor lock-in. No thanks.
Any good starting points or tutorials you recommend?
I am in the business of provisioning custom AI robots for paying customers. I need to be able to provide certain assurances and offer operational simplicity or the whole thing falls apart. These systems need to survive in their environments. Accounting and compliance teams feel a lot more comfortable with the landscape around the frontier model companies.
If I went to my favorite client on Monday and tried to sell them what HN seems to think is the most ideologically pure AI solution, I would probably be fired as a vendor.
It's not trivial, but cmon, i did during weekends from my phone and FOR ME it's so much better than the codex or claude, it has every i need and want :D
I'm using my own harness for work and hobby, has github integration, review mode, interactive voice mode, overlayed worktree, browser integration, mcp and much more.
Using claude and codex feels like picking up a club, in-line with the caveman skill...
And yet, I find Pi so much better to work with than Claude Code.
(In fact, "need to support mobile" is the main reason given for the loss of personality from the web as a whole!)
> Steer clear of load-bearing tech debt as your agents evolve.
Satirical?
That was yesterday. I think the crown currently belongs to DeepSeek Flash v4.1 for the next few days or weeks.
I’ve been doing this for the past few months. I started with a server where I ran pi in tmux and then used that to build an LLM gateway and agent session manager, then built deterministic workflows using bash scripts and a skill/script distribution system. The app works on desktop, mobile and web and it works great. Non technical colleagues are using it to build and ship real software and it’s cheap AF even using API pricing because it works well with Luna or deepseek.
I had issues with some other models but it seems to do with the system prompt and tool calling format. Some models seem to only work well with some harnesses.
I made my own harness based on this, which I jerry rigged to a Codex sub.
It would be trivial for every request to clone a full lxd container and have all the tools and repos required if I wanted to allow it to do even more.
Not sure why anyone prefers to choose locked in options
Convenience. And OPEX vs CAPEX something something.
https://github.com/omnara-ai/omnara - this is a self hostable agent API that I'm working on. It stores the state of all agents in a postgres db you can easily query, rather than a local json file or sqlite file per agent.
Also yes to an open runtime.
The intent is that anybody can drive it from Claude/ChatGPT/Pi on their phone after MCP sign-in (oauth), the model has full computer use capability, but we can also leverage it to build guided agent workflows in our own dashboard.
Async tool calls, having the agent wait indefinitely for a human response, and showing a form or questions to the user via a tool call are a few common capabilities that come up that a product manager might miss at first.
This is why I've been building Nvoken. LLM agnostic, ergonomic SDKs, flexible tool call patterns, tenant and user-aware budget enforcement, etc.
I'd really appreciate any and all feedback on this! It gives you some free tokens on signup and it's super quick to try.
All of this is specified in the ACP spec, so if you build your agents from that - you don't end up skipping features.
Also vital is proper prompt caching, tool design and some connection retry mechanism.
Oh good reminder. I need to do that.
> Also vital is proper prompt caching, tool design and some connection retry mechanism.
prompt caching is weirder than i originally thought, and so variable across providers. Retry is easy, but can you explain more on tool design?
Spider men meme of developers pointing at each other thinking "Not it".
Going off and searching the web isn't really it.
You need to create 'new worlds' where they can operate best - and even then constrain what it does.
https://developers.openai.com/api/docs/guides/agents-api/env...
That makes this much more enticing, and potentially eases transition between providers.
Yes, the lock-in is real and only good for OpenAI, but there's absolutely demand for managed services where you defer the responsibility of security patching; scaling; uptime, etc to a third party provider. Just like why people use AWS/GCP/etc over bare metal in a colo.
Honestly works extremely well as a personal assistant.
I can see why turning it into an API makes sense, just be aware you might not need to lock yourself in if you can setup your own VMs.
Setting up all my code, environment, context, etc in the cloud on VMs seemed like a lot so instead I send back tasks to my Mac mini(s) that are running at home.
Works really well and is a great use case for work laptops. Same shell, same memories, same sessions
Pretty easy these days with old school tools like tmux but more modern tooling like herdr [0] is really the path you'd want to take.
you can just make new sessions for each new task?
i just give it a config (agents.md etc) to where it knows what's going on, or can figure it out
Sometimes start a new chat in the phone app, sometimes just add to the main one. Both seem to work ok.
If I want the agent to wait for something I need to start a new chat in the iphone app.
When you're using ChatGPT/Claude/Gemini etc. you're basically already interacting with some backend harness with tools etc., not a raw LLM. Just give it a computer and be done with it.
I already find myself using Claude Code / Antigravity (via web) instead of Claude / Gemini, even for tasks unrelated to coding. Why use a limited version?
Because in most of those API, even many implementations of the Responses API, you lose a lot of control of where your data is going. e.g. an Agent or the Responses API may automatically invoke a tool call that leaks your data to an external service on the internet, without having an option to intervene.
If you want to have control over your data, you have to have control over your harness.
In so many cases, all the friction is about how to provision access to local data so the agent can work. So you started with the problem of how do I integrate an agent that is running locally with data that is hosted locally, and you have to deal with a bunch of security, data sensitivity and management issues around that. Now you moved the agent to a remote host - pretty much all your problems are worse: now I have a remote agent reaching into my infrastructure to deal with.
I'd much rather the inverse of this: let me run the agent local but provide secure remote hosted sandboxes. That actually solves a real problem because the sandbox running locally means breaking out of it directly intersects your local infra, whereas if it runs in a managed hosted environment I can leave the provisioning and management of that to someone else.
Kind of slack-button-click-to-fix-something workflow.
Btw, the crawlers are for classical music websites, the project is https://classicalbot.com/ .
I built it primarily for ourselves: we are building an AI data engineer, and we need a way to run many of them in parallel securely. An API for this seemed like the most obvious path forward. It makes it trivial to bring agentic capabilities into any product surface without having to deal with sandboxes, reliability issues, compatibility problems, and more.
I think it also makes sense from OpenAI's perspective to do this, but also we did find ourselves needing to change models and harnesses quite a bit, which is why I think this needs to be a layer of its own above the labs. It also needs to be a layer above the sandboxes, since many of them are quite brittle.
Overall, I expect a lot of the agent implementations to move in this direction. I think this is a lot saner for engineers to implement and maintain, and it makes it trivial to build agentic stuff into products.
We've seen this pattern with Apple making their own version of an app that was previously popular on the app store.
The labs are in a perfect position to do this - they have a bunch of data on what's being used and they have direct access to their own models/compute. If an external service is popular, it's relatively trivial for them to estimate how much additional profit they're leaving on the table.
If the usecase isn't far from their core business (and things like this absolutely aren't), with their size, why wouldn't they eat other people's lunches?
This area should be open source and supported by the cloud providers. Because I don't really want to be locked to a model provider when I am building my agents.
Actually this is happening, I found couples:
- https://flueframework.com from Astra - https://eve.dev from Vercel - https://fastagent.sh looks more independent, cloud neutral
There should be more and more options, the OpenAI Agent API may be another GPTs
Instead they'll point you to their respective vendor APIs for the specific use cases.
We're talking about trillions in value to be captured, they'll try everything.
It's going to destroy a lot of startups which were monetizing this exact idea. But clearly it's a low-hanging fruit so it makes sense that OpenAI would do it.