A clawful of competition lessons, "part 2"
This is the second article in my ongoing series of OpenClaw.
My first covered the first “big” surprise learning with OpenClaw. The lesson being that you can’t know what you’d use OpenClaw for until you start using it. Sounds strange, but that’s the world we live in. You can read the ideas around “Path Revelation” below. Meanwhile, let’s shift to our next lesson in running the “Surprise into AI” competition with OpenClaw: the UseCase.
While at NVIDIA GTC this year one of the helpful staff on the floor got to talking to me about OpenClaw use-cases. It was a lively, fun conversation. However, I got to wondering about words.
When did the word UseCase even enter the lexicon?
Have you ever given thought to when the idea of UseCase first entered modern thought? After all, it’s a fairly modern invention-and everyone just lobs it around like they know what it means. But do they?
I won’t toss around the letters UML, but if you know UML you may already know the answer to the origin of “UseCase”.
Disclaimer: I had Gemini help me do just enough history review-so forgive me for a little AI insertion here. I think you’ll find it interesting, too.
The Architect: Ivar Jacobson
The UseCase concept was pioneered by Ivar Jacobson, a Swedish computer scientist, in the late 1960s and early 1970s while he was working at Ericsson.
At the time, Jacobson was grappling with the complexity of large-scale telecommunication systems. He realized that traditional requirements gathering—which usually involved massive, technical lists of “the system shall...”—failed to capture how real people actually interacted with the technology.
Evolution of the Term
-
1967: Jacobson first used the term användningsfall in Swedish, which roughly translates to “situation of usage” or “usage case.”
-
1986: He introduced the concept to the global software engineering community in a formal paper titled “Language Support for Changeable Design,” presented at the OOPSLA conference.
-
1992: Jacobson published the seminal book, Object-Oriented Software Engineering: A Use Case Driven Approach, which solidified the methodology.
I’d be willing to bet if you read the book Object-Oriented Software Engineering, you’d learning at least one new idea. I’ve always been delighted in reading old engineering books. There’s always some musing or side reference that speaks to this exact moment.
Eric’s UseCase of OpenClaw
OK, so that aside what was my UseCase? I covered it in the videos I published for the competition and I’ll now outline more of those details. The idea is simple enough: I’d use OpenClaw to manage the competition. If I could do that, then I could anything.
“Anything is a strong word, Eric.”
It is, but it’s a structured argument. Consider what is involved in running a competition. You need scoring, submissions, validation, communication, dispute resolution, deadlines, incentives, and (subtle but profound) trust in the system.
That’s where most tools quietly fall apart-do you know why vibecoded apps go without users? The answer is simple three beer in. Trust. There’s no credential signaling that shows your vibe coded app has trustworthy features. Give that some deliberation, it’ll explain so much.
Vibe coded apps or one-off tools (or SaaS!) handle one or two of those pieces well. Maybe they’re great at collecting submissions, or maybe they excel at displaying a leaderboard. But the moment you try to stitch everything together into a coherent, end-to-end flow, you start reaching for spreadsheets, ad hoc scripts, Slack threads, and manual overrides. The system fractures, and now you are the system. “Just one more system bro, and it’ll work” Nah, I’ll pass.
That’s the real problem I was trying to solve.
So my use case for OpenClaw wasn’t “run a competition” in the narrow sense…it was to see whether I could define a complete, self-contained operational loop:
-
Participants submit entries
-
The system validates and scores them
-
Results are surfaced transparently
-
Edge cases are handled deterministically
-
Communication happens in context
-
And everything is reproducible without human intervention
If OpenClaw could handle that, then it wasn’t just a niche tool. What it meant that OpenClaw? It was a general-purpose orchestration layer for any problem domain.
That’s why it’s so important: we’ve automated everything.
Because a competition is just a compressed version of a much broader class of problems. It’s a microcosm of operations: inputs, rules, evaluation, outputs, and feedback loops under time pressure. Swap “participants” for “users,” “submissions” for “transactions,” and “scores” for “decisions,” and you’re suddenly describing half the systems we build in fintech, marketplaces, and internal tooling. It’s everything, everywhere.
That’s why I said “anything.”
Not because OpenClaw literally does everything-lord knows it takes work. But (and big but) because if you and your OpenClaw can survive the chaos of a live competition, with real users probing every edge case and ambiguity, then it has the primitives needed to model far more complex workflows.
It did better than I thought- but also worse. I’m not sure who learned more by the end. My OpenClaw instance or me. Let’s talk about Competitions, generally.
Competitions
I compete in a lot of tournaments. One “benefit” of either competing in sword slinging tournaments or volunteering for a lot of oddball tournaments is that you get a sense for how they operate. There’s a certain rhythm to them all. Yet, at the end of the day they all share certain some commonalities and some not.
You haven’t lived until you volunteer for the mudrun to help the other races trudge along the race way. while you stand in half a foot of mud as ice-cold November Rain comes falling down. You’re freezing. You can’t feel your toes. There’s no glory here for you. There’s simply the beautiful moment of you standing in the brutality of nature pointing the way forward.
Fencing tournaments are where the illusion of order really sharpens.
On paper, they’re pristine. Pools flow into direct elimination. Touches are counted. Priority is assigned. There are rules for everything, down to the angle of a shrug. It feels like a closed system. Deterministic. Fair.
And then you show up… and it’s always a new something new from the bag of "what could go wrong this time”.
The bout committee is already behind. Someone’s name is misspelled, which means they don’t exist, which means they can’t fence, which means they will fence anyway, but now outside the system. A strip goes dead. A referee disappears into the void. Another is arguing… “politely”, but with the quiet intensity of a blood feud, over right-of-way rules I barely understand and that no one else saw. Half the fencers are pacing like caged animals. The other half are sitting on the floor, wrapped in cords like they’ve been claimed by the machine. You’ll stumble on philosophy books scattered about like studying existential philosophy prior to your match gives you an edge.
There’s always a moment, usually mid-pool, where time stops behaving correctly.
You were supposed to fence at 10:40. It is now 12:15. No one can explain why. It’s magic. All that pre-game warmup routine? You’ve been thru it four times.
Despite all of that … it works. Not cleanly. Not efficiently. But it converges. Results emerge from the chaos like something dredged up from a dark lake. You get your seeding. You get your tableau. You fence your way to wherever you were always going to end up.
That “rhythm” I mentioned earlier? It isn’t order. It’s recovery.
Fencing tournaments are less like a well-oiled machine and more like a system that is constantly failing and in ways that are known, tolerated, and quietly corrected by humans in the loop. The bout committee patches holes. Referees improvise. Athletes adapt. Everyone participates in keeping the illusion intact.
Which brings me back to OpenClaw.
Because what I wasn’t trying to model was the ideal version of a tournament. Anyone can do that. A clean bracket, a neat progression, perfectly timed rounds-that’s just a diagram. This is what vibecoded software gets wrong-you don’t need the perfect tool for a perfect world. You need the chaotic mess of tools and Milwaukee accessories to get the job done.
What I wanted to capture was the actual system:
-
The missing fencer who still needs to be placed
-
The late result that invalidates three downstream assumptions
-
The dispute that can’t be cleanly resolved but still needs an outcome
-
The schedule that drifts, then drifts again, until time itself becomes advisory
In other words, the parts that are usually handled by tired humans making judgment calls under fluorescent lights.
If OpenClaw can’t deal with that, then it’s not useful. It’d fail pretty fast, to be frank.
That’s the bar I was setting: either it’d work or it’d implode.
Could OpenClaw take in inconsistent, delayed, partially wrong information and still produce something coherent on the other side? Could it preserve enough structure to be trusted, while allowing enough flexibility to survive contact with reality?
Because that’s what every tournament is: a negotiation between what’s supposed to happen and what actually does.
And if you’ve ever stood there, mask half on, watching your pool sheet get rewritten for the third time while someone yells for a referee that may or may not exist… well, you understand something most system designers don’t:
The system isn’t the bracket-those are just lines and letters on a piece of paper. It’s march madness season right now. You might even be an expert on brackets. In a competition, as an athlete...? I see it differently.
The system is everything that keeps the bracket from collapsing.
And systemsare worlds, but I’m getting ahead of myself for this short article…which has already beaten the dead horse as to why I selected OpenClaw to manage the competition, but these messy details are important to understand what happened next.
Thanks for reading! Subscribe for when part 3 drops.
UseCase for OpenClaw
So now you know why I considered using OpenClaw to manage the “Spring into AI” competition. In part 3, I’ll cover more lessons learned.
Really, I pointed OpenClaw at the “Spring into AI” competition and, with a level of confidence that can only be described as either admirable or deeply questionable, decided it should be the thing responsible for holding it all together. I hope that much is clear. It did really well-after I learned a few things.
But let’s recall why I chose a competition for this.
Not because competitions are orderly. They are not. TV lies. They only appear that way from a distance, much like a well-run city looks clean until you notice the alleyways, the improvised shortcuts, and the one person who is absolutely not where they are supposed to be but is somehow still part of the process anyway.
Competitions are systems that succeed not because everything goes right, but because enough things go right at roughly the same time for long enough to produce an outcome that people accept as real.
That is what makes them useful as a test.
A competition does not politely follow your model of “what should be”. It interrogates such a construct. A competition finds the edge cases you did not think were edge cases. It introduces timing issues, partial information, and humans who are entirely convinced they are correct. It creates situations where the “right” answer is less important than having an answer that the system can stand behind without collapsing under its own contradictions.
If your tool only works when inputs are clean, when timing is perfect, and when every participant behaves as expected, then you do not have a system. You have a diagram that has not yet been exposed to reality. And reality, in my experience, has very little interest in cooperating with diagrams.
What I wanted to know was whether OpenClaw could do something more difficult and far more useful. Could it take in information that was late, inconsistent, or slightly wrong and still produce something coherent on the other side? Could it preserve enough structure that people trusted the outcome, while remaining flexible enough to adapt when the inevitable deviations occurred? Could it, in other words, behave less like a brittle machine and more like the quiet, slightly overworked tournament committee that somehow keeps everything moving forward despite clear evidence that it should have fallen apart hours ago?
To its credit, OpenClaw did not collapse. It bent. I cried. I shouted tears of joy. It adapted. I did yoga. It occasionally did something that made me pause and ask whether I had misunderstood my own rules-who was at fault, me or it? But it kept going-I kept going. Learning, adapting, iterating. And that matters more than elegance in systems like this… action. A system that survives is infinitely more valuable than one that is correct until the moment it is not.
And action reveals what needs to happen next.
Adapted from the original Substack post: OpenClaw UseCase: Managing Competitions.