Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I think we’re still figuring out the right abstraction for offering agents as a product.

- 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.

 help



> building your own harness is a huge undertaking, a deep rabbit hole.

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.


I built my harness in pi within herdr, I cloned (zipped and downloaded) 0xRichardH/pi-herdr-subagents and went from there, and used pi to build itself, adding gate workflow state control, provider fallbacks (I use many token plans), subagent skill injection, etc.

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.


Correct me if I'm wrong, but the harness will always be dependent on the underlying model, and useless without it. All custom harnesses are being built, could be obsolete in the next big-generation-jump of the models.

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.


I switched between several local and remote providers and models and over different API (anthropic/openai) and it worked fine, just some minor issues but they were fixed within an hour.

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.


Doesn't apply to every scenario where agents are useful. Think about businesses - most business processes are not optimized this way. They are mostly a conglomeration of hierarchy, relationships, customs, IP, etc. Model development will never cross such paths. Thus, harnesses are needed. A foundational system that covers 80% of business processes has value, and I'm targeting that problem --- https://github.com/rush86999/atom

Counter point to “complex businesses” is they’re currently buying Copilot licenses for their employees, with the hopes it can intermingle with Office365. Very ineffective, I think, buy from my exposure the “non-tech” side of things is not on the same timeline as us.

That’s also one of the reasons why I think harnesses might be obsolete in a year, or re-defined completely.

Obviously, once again, I might be completely wrong. But my thesis is investing hard on any model/harness/custom builds might be counter productive given the speed of development. It’s not easy, but having a nimble org where you can swap things around might be a good call.


You are wrong. I honestly am having trouble understanding how you think these things work, and what you believe a harness is in the first place.

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.


Sorry, I didn’t mean to imply that what you’re doing is wrong, although re-reading my own comment sounds like so.

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.


> The capabilities of a model unlocks certain harness behaviour, and in its terms might be beneficial to automate more of your x, y, z.

Not really.

Sure its nice for a model to nativly be trained on understanding browsers & DOM/js model, so it can effectively use a `browser` tool.

A model needs a certain 3d mental model before it can successfully use a `blender` tool. Opus 4.5 had this to some extend without specifically training for it - but sure this is one aspect i think models will rapidly improve on this year.

But at the same time these tools carry a description of how they're used specifically - so changing out the `blender` tool for some other 3d modeling software shouldn't affect its capabilities. Using/creating a coherent description of the desired art-style is most of the value of the work.

So its still not clear to me what you mean with "certain harness behavior" or "unlock new capabilities".

You get access to a model that can be better or worse at certain tasks, sure.

The big change i've noticed last year is they've gotten better at prompting themselves (subagents, delegate, w/e you want to call it).

But the explosion of how fast things went last year is mostly "existing software * better model". For that capability explosion to continue you'd need ever more "software" that improve with AI (or more existing software unblocking their interface for model use)

There will definitely be more software, but you need time to incorporate it in your work (like eg `git`) for it to meaningfully feels like AI is unlocking new things when using it.

For new stuff like being able to control a robot dog, we first all need to have a robot dog for it to feel like very fast development.

----

As for "Computer use" specifically that seems like a bad example from my perspective.

The only real "added capabilities" over the past year i've seen is better selfprompt + comprehending screenshots.

Every other use case i'd consider computer-use is just friction that needn't have been there in the first place. Its the software/os you're using that doesnt have a proper interface that's creating the friction. Not the lack of model/harness capabilities.

I have had a `browser` tool for a year that's just a debug-socket to ff/chrome with eval + pre/post screenshot, and ever since 4.4 ~ 4.5 every model has understood it just fine and can do basically anything.

Reasoning _what_ to do with it is the 'intelligence' we're trying to benchmark and everything since Opus 4.5 was basically 'good enough' for anything non-creative a human could do.

E.g. having a model get good at creating drafts of emails based on support tickets, is a function of how good the cli/mcp and instructions are.

Can you be more specific in what capability increase you see getting unlocked?

As a final point, the models are so good now that you can ask claude inside claude to write/setup plugins for pi to do everything claude can do.

The reason i dont use pi to ask to improve the claude harness, is because anthropic is trying to build a moat with their closed source crap. They'll succeed because enterprise is slow to adapt and doesn't understand its wasting money, not because their models unlock certain harness behavior. The competition who is not wasting money will have a step up.


A lot of what a custom harness does isn't necessarily interacting with a model, it's the framework around it. Part of harness engineering is figuring out what can be done deterministically to avoid calling an LLM. A generational jump doesn't obsolete those areas, it just means you get the right answer (maybe) faster and easier when you do call the model.

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.


We might have different views on where the SE as a profession is headed, I think. Again, I might be wrong, nobody knows the future, but we didn’t even use the word “harness” that much a year ago. There’s a decent chance in two years the harness itself as a concept might be obsolete. Depended on how fast your teams move, investing in a custom harness might be a bad resource allocation. Unless, obviously you’re in top tier companies which can benefit from it and pivot fast.

Again, this is all subjective risk assessment. I very much support any engineer to learn how to make harnesses, and I, myself, have a long way to go. We’ll see where we are in a year or two, I guess.


I cannot agree more. We all have our own needs, and it’s never been easier to make something that meets them exactly.

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. It didn’t start that way, it was originally all in on Claude, but now all the things I built on top of Claude now work with the others too.


I did a similar thing, took those sub agents primitives and ran with it: https://github.com/durdn/herdr-interactive-subagents I do still use more than one harness though.

I also built a custom harness tailored to my needs using pi.dev underneath. From time to time I use the 'official' harnesses of openai/anthropic but can't confirm that they are much better adapted to that harness.

100% every professional developer at some point should build its own harness as daily driver

I'm very interested in this but I am confused on what Pi provides you if you are building the harness? What does Pi get you that writing from scratch doesn't?

Any good starting points or tutorials you recommend?


Pi is just a nice base and it has defined extension protocols and such. You might as well start there, it's just easier and going from nothing to working to adding whatever functionality is like 2 minutes.

After being burned by the rug-pull of OpenAI retiring the Assistants API in favor of Responses last year, I swore off using heavily stateful APIs for language model access. I could be totally wrong, but at this point I'm more willing to use a proprietary harness headless than to abstract it into an API.

A good harness is a universal harness. It should not depend on the model at all. I foresee harness being the edge that people have.

For instance, if you are able to encode laws as a lean program, that would be an absolutely insane harness that would make you leap way ahead of your competitor.

Right now, I am interested in creating a personal assistant. It is crucial that this is done privately and safely. To do this, I run a local gemma4 model that have access to a copy of my emails. The only outside world that it can interact with is a private Telegram chat that I have with it.


I've been working on a custom managed agent (see my other top-level comment), I find it is actually a manageable undertaking. It does feel herculean, but somehow doable. I do not find their hidden reasoning tokens to be insurmountable as long as you match the behavior of codex or CC (which takes work, but, again, is doable). My managed agent harness currently matches Codex on several benchmarks like Terminal Bench.

I feel like you could use an open-source harness like Pi and get 100+% of what these closed APIs offer without getting locked to OpenAI. What do you think is missing from them?

Lack of risk to the business. If it was just me and my tinker toys, the open path makes a lot of sense.

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.


> > building your own harness is a huge undertaking, a deep rabbit hole. > I eventually gave up on this task.

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...


Yet i find claude code worse than opencode.

I don't think anyone who's tried something else can like claude code. The only reason to use it is the subsidized plan and nothing else.

But it does have some very cool features built in I haven't seen rolled in elsewhere. Sessions can talk to one another out of the box. Two left arrows and you see all the sessions. Automatic remote control to pick up a session from another computer or even on your phone. So convenient!

I could patch this together with Herdr and OMP and some custom server stuff but it works right out of the box!?


Cursor does all that and actually lets you look at the code

> It's not possible to fight OpenAI or Anthropic's engineering teams

And yet, I find Pi so much better to work with than Claude Code.


I don’t find it better than Claude Code but much better than OpenCode. So I am curious why less is more in that context.

I think the abstraction is only part of the problem. The other part is that all these companies offering ai products are deeply untrustworthy, and I don’t want to let them any further into my stack than I have to. Claude code and codex are great because they are lightweight, and operate on top of the rest of my tools with little to no change needed, so they can be eliminated or migrated away from with zero cost. They’re not a dependency of anything. And that’s as much as I’m willing to trust OpenAI or Claude.

Just letting you know, this comment inspired me to finally just say "screw it" and launch what I've been building for the past year. https://www.cadenya.com

Interesting web design. It's rare to see a mobile website with actual personality.

(In fact, "need to support mobile" is the main reason given for the loss of personality from the web as a whole!)


Interesting concept, but blue ocean as to your target customer. Would be good to see other case studies, use cases for this. Also, thank you for not another “bring your keys” product. Just abstract it away for me.

Congrats on the launch! The readme post in the blog was helpful to understand what you’re selling. Maybe you could convey those ideas more in the homepage?

Truly love the website.

Although I must say this threw me off:

> Steer clear of load-bearing tech debt as your agents evolve.

Satirical?


> A competitor who is not an LLM lab gets their pick of the market at any given moment

Exactly this. We're building an Agents-as-a-service API, would love to get your feedback: https://www.ellipsis.dev/docs/sessions


What is your use case? Your business model?

There is no "one harness". I don't feel your pain. I know, what quality has to be ensured, what's within boundaries and what not etc.

I work for price sensitive industries and here some information has to be factual correct. The error rate is 0% so far, 100% accuracy.

So what are you trying to harness?


> you’d want to be using GLM 5.3 Flash right now for most things agentic

That was yesterday. I think the crown currently belongs to DeepSeek Flash v4.1 for the next few days or weeks.


I can't wait for next week

> they’re stuck using their own proprietary frontier models and those aren’t actually the best choice for most agents right now

Are they stuck? What's preventing them from using open models or creating models more suited for those tasks?


There might not be a good abstraction. I've built a few harnesses for different types of workflows, and the details are so different I struggle to see a good abstraction. It's also not clear there should be - if you look at most complex software systems, it's a collection of smaller abstractions/tools/systems pulled together to achieve X.

> LLMs are a great foundation but building your own harness is a huge undertaking, a deep rabbit hole

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 also use Luna and DeepSeek in a custom harness. (Mine is very minimal.) GLM also works great.

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.


Ha yeah GLM and Kimi seem to always biff the tool calls. I recently added in a raw stream log switch to diagnose but since DS and Luna are so good and cheap I haven’t been that motivated to debug it …

This is the "i made a voice controlled agent" thread all over again. lol, I too have made a stable of harnesses and tools to run them and have different levels of them monitoring each other and different spends to code/review/triage.

I just have a slack bot running on a VM that sees a message and invokes pi.

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


> Not sure why anyone prefers to choose locked in options

Convenience. And OPEX vs CAPEX something something.


IMO building a harness is not wildly difficult (customize pi?) but the offerings from openai and anthropic are wildly subsidized in the subscriptions so they win by default if you want frontier capabilities. Glm 5.3 flash is great but it's not cheaper than a codex or Claude code 200 dollar sub and it does not have astra or fable level capabilities.

Try 50 lines!

https://minimal-agent.com/

I made my own harness based on this, which I jerry rigged to a Codex sub.


Agree, as long as models are interchangeable, it doesn't make sense to be locked into a single lab's managed agent platform. You probably want to swap between models and own the agent state.

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.


The best answer I’ve come to thus far is the model we (estuary.dev) are building out now: offering mcp.estuary.dev with tools for creating a sandbox with our CLI pre-installed, a tool for requesting that a tightly scoped access token be injected into a named sandbox file (this is the approval gate), and a tool for executing arbitrary commands in the sandbox (presumably our flowctl CLI, but let the model rip).

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.


Agents are the wrong paradigm entirely and have limited places where they actually belong.

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.


Libraries such as agent development kit (https://adk.dev/) provides abstraction over multiple LLM vendors, long-term memory (persistance + compaction) and allow us to manage subagents & their lifecycles. Vendor neutral memory & context management is a challenge as default long-term memory uses vertext AI (gemini) in ADK.

Is GLM 5.3 Flash that good? I'm using it through atlascloud for my current project and testing performance against opus and gemini models. I think I'm mostly concerned about speed because they are mostly doing tool calls.

Also yes to an open runtime.


Been using bedrock agent core and seems to work fine for me. Although there might be a better abstraction.

> Where does the state persist?

Spider men meme of developers pointing at each other thinking "Not it".


I built several harnesses in different products over the last two years. Fully agree with you that doing it right is a rabbit hole. Certain system properties that you almost always want in a harness used within a SaaS (for example) are non-obvious at the start and require certain architectural choices. It's easy to start down a path and then find a gap a couple days before launch.

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.

https://nvoken.com


> 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.

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.


> All of this is specified in the ACP spec

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?


I think things like onecli are the direction we will take. The secrets and state will be proxied api calls.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: