Hey HN, we've been running multi-agent orchestration pipelines at Frequency for a few weeks (wrote about the architecture previously on our blog). The recurring pattern we see is that most existing software resists agent operation in ways you only discover at scale. The friction is rarely in the API layer. It's embedded in the product's fundamental assumptions about the user being human: the data model, the interaction patterns, the state management.
What prompted this essay was our own trouble in utilising agents with exisitng tools resulting in us rebuilding products from the ground up. That made us think of the question of what happens when my customer is an agent shopping for the best tool to accomplish a human's task (which has been a question in a lot of peoples mind around the openclaw hype, whether openclaw is actually useful is another question). We think that reframing changes which products survive the transition.
Interested to hear from anyone else running agents against existing tools at scale. Are you seeing the same friction points, or has the adapter approach been working well enough for your use cases?
Hey HN. I've been running 10 agent pipelines in parallel for a few weeks. Agents come up with app ideas and ship them autonomously. The result is ~30 production apps with working payments and live users and most importantly apps that (in my humble opinion!) don't suck. I wanted to share the architecture and see how others are tackling orchestration.
To make this possible, I built Frequency, a config-driven orchestration layer where workflows are YAML state machines. State is repo-local JSON (no database, no message queue), agent calls run in git worktrees, and about 40% of steps are agent calls with 60% deterministic scripts.
The hardest problem for me was tackling cross-pipeline coordination. Marketing needs to know deploy finished and bug fixes need to flow back through build etc. We ended up with declarative predicates rather than imperative callbacks. The blog covers the three predicate types that handle the patterns we've hit.
Still figuring out: agent quality at scale (Claude reviewing Claude's code is tautological), non-deterministic throughput (2-5/5 pass rate depending on the day), and token limits are the main ceiling right now (which I guess is the better problem to have).
Curious what patterns others are seeing for multi-agent coordination. Are all of you solving this differently?
I'd love to learn more and hear feedback about what I can do differently, and if this tool would be useful to anyone else.
I've been playing around with agent orchestration recently and at least tried to make useful outputs. The biggest differences were having pipelines talk to each other and making most of the work deterministic scripts instead of more LLM calls (funnily enough).
Hey HN. We built Frequency, AI agent orchestration that autonomously detects, defines, and runs any repeatable workflow in your repo for you, continuously and at scale.
We used it to automate our app development repo, and rapidly ship 30 production apps (and counting) at Cashew Crate (https://cashewcrate.com) from scratch, autonomously. These are real, fully functional apps with working payments, accounts, analytics, and marketing integrations. Now, all we need to do is run Frequency and we see new apps appear everyday, without any prompting or babysitting.
While we needed to intervene to set up payments for the first time due to regulatory verification, the agents handled everything else - ideation, implementation, review, deployment, and bug fixes across 10 parallel pipelines (more pipelines can be added as needed).
Frequency analyses your codebase, generates workflow config as YAML state machines, and runs them with repo-local JSON state (no database, no message queue). Pipelines coordinate through state predicates and shared resource locks. Agent calls run in git worktrees with integration gates. About 40% of our steps are agent calls, the rest are deterministic scripts. Works with any agent or CLI tool. App development was our proving ground but the runtime is workflow-agnostic.
The hardest part was cross-pipeline coordination: marketing needs to know deploy finished, bug fixes need to feed back through build. Getting this to work declaratively rather than with imperative callbacks took several iterations. Our main bottleneck now is token limits rather than the orchestration.
We're opening Frequency to design partners. If you want agents building and running your workflows autonomously, safely and at scale, sign up at http://frequency.sh.