OpenClaw is an application, not a harness. Yes, it contains a harness, but it is a complete product.
When building an agentic workflow there are enough primitives that rewriting them from scratch every time makes zero sense.
What is a tool? How does the LLM understand the tool? Formatting a native function into a serializable input/output pattern makes sense to generalize and that does not need to exist repeated in everyones application code.
We use libraries to interact with the APIs themselves; nobody would say writing a spec-compliant API client was poor practice. Agentic harnesses are just one layer above: I need to call the API and I need to do it with certain expected conventions.
One, obviously yes OC contains a lot more than a harness, but my point was that it was too much for their use case and constrained their choices, not enabled them, and that choosing the right layer of abstraction is important.
There's good indirection/abstraction and there's ones that do not serve your use case, eg what was obviously day one regarding Langchain.
Yes, Python has decorators, but they're best used as "filters" that apply to functions or methods. Cache this, serialize the output of this function always, prepare this function to be used as a tool by an agentic harness. Not registration, not flow control. You may disagree but someone has to say it; FastAPI influenced the modern use of decorators far too much in the wrong direction.
Builder patterns are a Rust convention, because Rust has no named keyword arguments. A Python function already exposes a named contract. There is very little reason to ever to sequentially pass configuration parameters in chained method calls. If you need to add state that doesn't exist yet to a constructor or factory, that is not a builder pattern. That is registration. The one place where builder patterns should be tolerated is query builders. They iteratively build on a concept and having the additional "slot" for metadata (method name plus keyword arguments) is genuinely useful. Using methods which accept single parameter instead of keyword arguments is incorrect.
So decorators here specifically attach metadata to make a function a reusable component. Builder makes a workflow. In Hamilton it's all decorators because it's purely declarative construction (sans reusability, really).
Doesn't look any different than doing the same in C# or Java to me, it is kind of pointless in Python, the one thing the pattern gives you is building a class in such a way that you the developer know exactly what's what, so its really a developer ergonomics thing is how it looks like to me.
There are certainly edge cases where you want native USB and display, but after initial bring up, the device is on the network, and can be managed over the network.
So, sure, nerd out and add more hardware to your rack, but I need a physical keyboard and mouse attached to a machine in my rack like once per year.
It's more nuanced than this. Peter Scholze said in response to this declaration:
> The goal of mathematical research is human understanding of mathematics, and so mathematics can only thrive in a community of human mathematicians. It is crucial to preserve this communal spirit. [0]
Terence Tao has also talked about the requirement for a mathematical proof: along with generation and formal verification, there is an important step of "proof digestion"
> understanding the essence of a solution, placing it in context with previous literature, summarizing and explaining it effectively, and gaining insights on other related problems and topics [1]
And the goal of computer mathematics research is computer understanding of mathematics. I fail to see a reason provided as to why society should defund automated reasoning just so mathematicians can put off burger flipping for another year.
But this is a blatant misapplication of the technology in an obviously sensitive use case with an implementation that's so exploitable the people driving it have certainly never heard the term "jailbreak" once in their lives.
Reminds me of a consulting call that I had with a very large internet provider about their new agentic chat support system.
"We're going to start with the request routing layer and move that to AI agents, and then work though the individual services."
I thought it was a wild architectural decision that they would choose to roll every single action that the system handled through an experimental layer. My advice was to start with a safe, repeatable process to validate the effectiveness in the wild, and then expand in the same manner, bringing edges in as they had "solved" the individual implementations.
So, while this is almost the exact opposite of that, choosing a high-value target with real repercussions as their leaf implementation still baffles me. Step zero of any AI integration plan should be prioritization. Companies are routinely failing at this very simple, not-even-technical aspect.
Losing two weeks while you try out a candidates fit has way less cost than bringing the wrong person on formally and spending the next year debating wether they were the right choice or not with all of the associated "soft" overhead.
This is my preferred proposal to new contacts as well (I set it up as a contract so there's a little less red tape, but even people that pursue me for traditional employment afterword usually land on an extended contract).
Two things it solves: You get to evaluate me, my ability to deliver, and how I interact with your team and I either bring real value within two weeks, or I don't. I can tell you verbally I am an indispensable asset or I can show you; other people have ruined the verbal trust layer which is why this whole debacle exists in the first place btw.
And more importantly, but less communicated, I get to evaluate you. How your team works, the level of talent present, management's ability to keep direction, and wether I genuinely enjoy what you have for me to work on.
My experience with this is that contract is usually better paid than perm, so when it comes time to convert to perm I am not willing to take the pay cut so I go contract somewhere else, or remain with them as a repeat contractor.
HR usually stops my clients from hiring me perm at 2X the rate they pay their full time employees, despite the strong demonstration of competence that I’ve shown over the last few months.
My clients are usually unable to make permanent employment with them more appealing than repeat contracting with them.
Fast is a Netflix product so the fact that you've even heard of it is in direct relation to the weight of the brand that launched it.
speedtest.net has been the first search result on Google for "speed test" for decades. Partly the boost of domain SEO and partly the boost of it being an effective exit node for searches for that term for that long.
(Nobody searches "ookla" and nobody is going to search your tier-3 .com)
When building an agentic workflow there are enough primitives that rewriting them from scratch every time makes zero sense.
What is a tool? How does the LLM understand the tool? Formatting a native function into a serializable input/output pattern makes sense to generalize and that does not need to exist repeated in everyones application code.
We use libraries to interact with the APIs themselves; nobody would say writing a spec-compliant API client was poor practice. Agentic harnesses are just one layer above: I need to call the API and I need to do it with certain expected conventions.
reply