[HN Gopher] Launch HN: Spine Swarm (YC S23) - AI agents that col...
___________________________________________________________________
Launch HN: Spine Swarm (YC S23) - AI agents that collaborate on a
visual canvas
Hey HN! We're Ashwin and Akshay from Spine AI
(https://www.getspine.ai). Spine Swarm is a multi-agent system that
works on an infinite visual canvas to complete complex non-coding
projects: competitive analysis, financial modeling, SEO audits,
pitch decks, interactive prototypes, and more. Here's a video of it
in action: https://www.youtube.com/watch?v=R_2-ggpZz0Q. We've been
friends for over 13 years. We took our first ML course together at
NTU, in a part of campus called North Spine, which is where the
name comes from. We went through YC in S23 and have spent about 3
years building Spine across many product iterations. The core
idea: chat is the wrong interface for complex AI work. It's a
linear thread, and real projects aren't linear. Sure, you can ask a
chatbot to reference the financial model from earlier in the
thread, or run research and market sizing together, but you're
trusting the model to juggle that context implicitly. There's no
way to see how it's connecting the pieces, no way to correct one
step without rerunning everything, and no way to branch off and
explore two strategies side by side. ChatGPT was a demo that blew
up, and chat stuck around as the default interface, not because
it's the right abstraction. We thought humans and agents needed a
real workspace where the structure of the work is explicit and
user-controllable, not hidden inside a context window. So we built
an infinite visual canvas where you think in blocks instead of
threads. Each block is our abstraction on top of AI models. There
are dedicated block types for LLM calls, image generation, web
browsing, apps, slides, spreadsheets, and more. Think of them as
Lego bricks for AI workflows: each one does something specific, but
they can be snapped together and composed in many different ways.
You can connect any block to any other block, and that connection
guarantees the passing of context regardless of block type. The
whole system is model-agnostic, so in a single workflow you can go
from an OpenAI LLM call, to an image generation mode like Nano
Banana Pro, to Claude generating an interactive app, each block
using whatever model fits best. Multiple blocks can fan out from
the same input, analyzing it in different ways with different
models, then feed their outputs into a downstream block that
synthesizes the results. The first version of the canvas was fully
manual. Users entered prompts, chose models, ran blocks, and made
connections themselves. It clicked with founders and product
managers because they could branch in different directions from the
same starting point: take a product idea and generate a prototype
in one branch, a PRD in another, a competitive critique in a third,
and a pitch deck in a fourth, all sharing the same upstream
context. But new users didn't want to learn the interface. They
kept asking us to build a chat layer that would generate and
connect blocks on their behalf, to replicate the way we were using
the tool. So we built that, and in doing so discovered something we
didn't expect: the agents were capable of running autonomously for
hours, producing complete deliverables. It turned out agents could
run longer and keep their context windows clean by delegating work
to blocks and storing intermediary context on the canvas, rather
than holding everything in a single context window. Here's how it
works now. When you submit a task, a central orchestrator
decomposes it into subtasks and delegates each to specialized
persona agents. These agents operate on the canvas blocks and can
override default settings, primarily the model and prompt, to fit
each subtask. Agents pick the best model for each block and
sometimes run the same block with multiple models to compare and
synthesize outputs. Multiple agents work in parallel when their
subtasks don't have dependencies, and downstream agents
automatically receive context from upstream work. The user doesn't
configure any of this. You can also dispatch multiple tasks at once
and the system will queue dependent ones or start independent ones
immediately. Agents aren't fully autonomous by default. Any agent
can pause execution and ask the user for clarification or feedback
before continuing, which keeps the human in the loop where it
matters. And once agents have produced output, you can select a
subset of blocks on the canvas and iterate on them through the chat
without rerunning the entire workflow. The canvas gives agents
something that filesystems and message-passing don't: a persistent,
structured representation of the entire project that any agent can
read and contribute to at any point. In typical multi-agent
systems, context degrades as it passes between agents. The canvas
addresses this because agents store intermediary results in blocks
rather than trying to hold everything in memory, and they leave
explicit structured handoffs designed to be consumed efficiently by
the next agent in the chain. Every step is also fully auditable, so
you can trace exactly how each agent arrived at its conclusions.
We ran benchmarks to validate what we were seeing. On Google
DeepMind's DeepSearchQA, which is 900 questions spanning 17 fields,
each structured as a causal chain where each step depends on
completing the previous one, Spine Swarm scored 87.6% on the full
dataset with zero human intervention. For the benchmark we used a
subset of block types relevant to the questions (LLM calls, web
browsing, table) and removed irrelevant ones like document,
spreadsheet, and slide generation. We also disabled human
clarification so agents ran fully independently. The agents were
not just auditable but also state of the art. The auditability also
exposed actual errors in an older benchmark (GAIA Level 3), cases
where the expected answer was wrong or ambiguous, which you'd never
catch with a black-box pipeline. We detail the methodology,
architecture, and benchmark errors in the full writeup:
https://blog.getspine.ai/spine-swarm-hits-1-on-gaia-level-3-...
Benchmarks measure accuracy on closed-ended questions. Turns out
the same architecture also leads to better open-ended outputs like
decks, reports, and prototypes with minimal supervision. We've seen
early users split into two camps: some watch the agents work and
jump in to redirect mid-flow, others queue a task and come back to
a finished deliverable. Both work because the canvas preserves the
full chain of work, so you can audit or intervene whenever you
want. A good first task to try: give it your website URL and ask
for a full SEO analysis, competitive landscape, and a prioritized
growth roadmap with a slide deck. You'll see multiple agents spin
up on the canvas simultaneously. People have also used it for
fundraising pitch decks with financial models, prototyping features
from screenshots and PRDs, competitive analysis reports and deep-
dive learning plans that research a topic from multiple angles and
produce structured material you can explore further. Pricing is
usage-based credits tied to block usage and the underlying models
used. Agents tend to use more credits than manual workflows because
they're tuned to get you the best possible outcome, which means
they pick the best blocks and do more work. Details here:
https://www.getspine.ai/pricing. There's a free tier, and one
honest caveat: we sized it to let you try a real task, but tasks
vary in complexity. If you run out before you've had a proper
chance to explore, email us at founders@getspine.ai and we'll work
with you. We'd love your feedback on the experience: what worked,
what didn't, and where it fell short. We're also curious how others
here approach complex, multi-step AI work beyond coding. What tools
are you using, and what breaks first? We'll be in the comments all
day.
Author : a24venka
Score : 77 points
Date : 2026-03-13 13:22 UTC (9 hours ago)
(HTM) web link (www.getspine.ai)
(TXT) w3m dump (www.getspine.ai)
| sebmellen wrote:
| Just as a tiny first piece of feedback, the main marketing
| website is very hard to understand or grok without a demo of how
| the tool works. Even just the quick YouTube video that you added
| in your post here, if embedded, would make a difference.
|
| There are so many "agentic tools" out there that it's really hard
| to see what differentiates this just based on the website.
| a24venka wrote:
| Thanks for the feedback! Definitely agree that we could do more
| with the marketing site. We're working on a gallery page to
| showcase some demos.
| stuckkeys wrote:
| [flagged]
| mlnj wrote:
| Elaborate?
| dang wrote:
| " _Please don 't post shallow dismissals, especially of other
| people's work. A good critical comment teaches us something._"
|
| https://news.ycombinator.com/newsguidelines.html
| jpbryan wrote:
| Why do I need a canvas to visualize the work that the agents are
| doing? I don't want to see their thought process, I just want the
| end product like how ChatGPT or Claude currently work.
| a24venka wrote:
| That is definitely a valid way of using Spine as well. You can
| just work in the chat and consume the deliverables similar to
| how you would in other tools.
|
| The canvas helps when you want to trace back why an output
| wasn't what you expected, or if you're curious to dig deeper.
|
| Even beyond auditability, the canvas also helps agents do
| better work: they can generate in parallel, explore branches,
| and pass context to each other in a structured way (especially
| useful for longer-running tasks).
| dude250711 wrote:
| Dark UI pattern: pretends that it is immediately usable only to
| redirect for sign-up.
| a24venka wrote:
| Fair point, we should be more upfront about the sign-up step.
| Given that tasks are long-running and token-intensive, we do
| need an auth barrier to protect against abuse, but we can
| definitely do a better job signaling that before you hit the
| canvas.
| garciasn wrote:
| Or, just show us in an animated GIF how the product works in
| practice. Then, should we somehow find benefit in a visual
| representation of a swarm's workflow, we could sign up rather
| than having to, unintuitively, scroll down to watch a YouTube
| video.
|
| e: 'be' to 'we'; oops.
| a24venka wrote:
| Good call and noted. We're working on making the product
| experience more visible upfront.
| gravity2060 wrote:
| Is it possible to build self-improving swarm loops? (ie swarm x
| builds a thing, swarm y critiques and improved x's work,
| repeat...)
| a24venka wrote:
| We've only partially explored this so far, but it's a great
| suggestion.
|
| The canvas architecture naturally supports this kind of loop
| since agents can already read and build on each other's outputs
| -- so the plumbing is there, it's more about building the right
| orchestration on top. Definitely something we're exploring.
| gravity2060 wrote:
| In the demo video you shared (yt link) how many credits did that
| whole project take? What is the prices to fix elements of it (for
| example of you dislike a minor aspect of the generated
| spreadsheet do follow up instructions utilize only the narrow
| subset of agents that has been demoed to that subtask, or does it
| create new agents who have to create new context in the narrow
| follow up task?)
| a24venka wrote:
| Credits are consumed by the blocks that get generated, not by
| the agents themselves. Some blocks are cheaper than others. A
| simple prompt or image block is a single model call, while
| browser use or deliverable blocks like documents and
| spreadsheets run models in a loop and cost more. Blocks also
| cost more when they have more blocks connected to them (more
| input tokens).
|
| In the demo video I shared, the task cost about ~7,000 credits
| since it ran around 10 BrowserUse blocks and produced multiple
| deliverables.
|
| If you want to fix a specific block (or set of blocks), you can
| select them and the chat will scope itself to primarily work on
| those. In that case fewer blocks run, so it's cheaper.
| nusl wrote:
| 7000 credits, ouch. The tool is really cool, I do think it's
| super useful. I also like the swarm particle animations in
| the backround.
| esafak wrote:
| Is the value prop that I can see what the agent is doing? This is
| not the way: https://youtu.be/R_2-ggpZz0Q?t=158
|
| How am I supposed to get anything out of this? Consider that
| agents are going to get faster and run more and more tasks in
| parallel. This is not manageable for a human to follow in real
| time. I can barely keep up with one agent in real-time, let alone
| a swarm.
|
| What I could see being useful is if you monitored the agents and
| notified me when one is in the middle of something that deserves
| my attention.
| a24venka wrote:
| This is a fair point, we are exploring progressive disclosure
| on the canvas to better utilize the space and make the key
| artifacts more readily visible. We do have other panels (the
| chat, task and deliverable) that have alternate views of what
| the agent did and the key deliverables.
|
| Beyond human auditability, the canvas helps the agents do a
| better job by generating in parallel, exploring branches and
| passing context to each other in a structured way.
| BloondAndDoom wrote:
| I didn't read the post, I checked out the website just like 99%
| of the people will do.
|
| Simple advice, if you are selling a product with a selling point
| of being visual, show it on your website. Not in a YouTube video
| but actual screenshots, short cut 10 sec video/gif
| a24venka wrote:
| Definite miss on our part, we're working on making the product
| experience more visible upfront on our landing page.
| salomonk_mur wrote:
| Friend, in the age of AI and even more so if you are selling
| an AI product, all you need is literally 2 screenshots and
| one prompt.
| metalliqaz wrote:
| There is an inverse relationship between how obviously
| useful a product is and how easy it is to produce
| screenshots.
| onion2k wrote:
| It's a shame the team don't have access to a product that would
| automatically research and implement what's needed on an AI
| product website.
| pqs wrote:
| I had to read this text in order to understand what this tool
| does, because I could not know from the website (without watching
| a video). You should use Spine to improve your website. ;-)
| gravity2060 wrote:
| What does it mean to say 30,000 monthly credits and 1500 daily
| refresh credits? If my project takes 7000 credits (the way your
| demo does) then does that mean I couldn't actually do it on the
| lowest available pricing plan because I couldn't use 7000 credits
| in one run? If this is the case, what am abysmal pricing model!
| a24venka wrote:
| The daily refresh isn't a cap on usage, it's additional credits
| you get each day (resets to 1,500 nightly regardless of use).
|
| You can use your full 30k balance in a single run if needed.
| The daily refresh just tops you back up over time so you're not
| waiting for a monthly reset.
| aleda145 wrote:
| Super cool!
|
| I'm completely sold on the canvas layer. Embracing non linearity
| is such a boon when you're on the ideas stage. When you have
| verified it though, moving it to another medium (a document,
| presentation or just code) is often the best choice.
|
| Do you see the canvases created with Spine as "one off" that you
| discard when you have got your deliverable, or as something
| living that you keep around?
|
| I'm building a side project for running SQL on a canvas
| (kavla.dev), so I'm thinking about canvas workflows all the time!
| a24venka wrote:
| Thanks! Great question. We see canvases as living workspaces,
| you can revisit, iterate on, and build on them over time.
|
| But the deliverables (docs, slides, code) are first-class
| outputs you can export and use independently. So it works both
| ways depending on the workflow.
|
| Kavla looks cool, canvas-based SQL is a great use case for this
| kind of thinking!
| aleda145 wrote:
| Nice! I'll make sure to try out Spine this weekend, if you
| want detailed feedback feel free to email me. You can find it
| in my profile.
| woeirua wrote:
| Interesting idea, I wanted to see an example of the agents
| working on a canvas when I opened your page. I saw nothing of the
| sort. Sorry, but immediate fail.
|
| This may be too harsh, but you need to make it immediately clear
| to someone today why they can't just have Claude Code one shot
| your app!
| a24venka wrote:
| This is good feedback and definitely something we are
| improving.
| kmoser wrote:
| I read "AI agents that collaborate on a visual canvas" and I
| thought it was a shared canvas (as in an image) that virtual
| agents could contribute to, sort of like an image-only
| Moltbook.
| airstrike wrote:
| Congrats on the launch! Meta comment, but I just ain't reading
| all of the above. You need to be able to explain this in about
| 20% the number of words or you'll lose people, _especially_ VC.
|
| My advice is to start with "Spine Swarm solves _____" then how,
| then why you're different. 3 short paragraphs, preferably 1-2
| sentences each.
| a24venka wrote:
| Agreed. We will make sure this comes through in our website.
| TheTaytay wrote:
| I think this is really neat. You should probably take it as a
| compliment that the biggest criticisms so far are about the
| website landing page. ;)
|
| I like canvases in general, and I especially like them for
| mentally organizing and referring to this sort of broad work.
| (Honestly, I think zoomable canvases would make a better window
| manager in general, but I digress)
|
| One small piece of friction: My default mouse-based ways of
| dragging the canvas around (that work in most canvases like
| Figma) aren't working. I saw that you had a tutorial, and I have
| learned to hold space now, but I prefer the "hold middle mouse
| button to drag my canvas view around".
|
| I've got a couple of research tasks running now, and my current
| open questions as a very new user are: 1) How easy will it be to
| store the outputs into a Github repository. 2) How easy will it
| be to refer back to this later? 3) Can I build upon it manually
| or automatically? 4) Can I (securely) share it with someone else
| for them to see and build upon it? 5) Can I do something
| "locally" with it? Not necessarily the model, but my preferred
| interface for LLMs at this point is Claude Code. Could I have a
| Claude Code instance running in one of these boxes somehow? 6)
| What if I want to do private stuff with it and don't like the
| traffic going through Spine's servers? Could I pay them for the
| interface, but bring my own keys? (Related: Can I self host
| somehow?) 7) When this is done, each artifact it found
| (screenshot, webpage, etc), is going to be helpful. The data-
| hoarder in me wants to make sure I can search these later. Heck,
| if I could do that, this would become my preferred "web browser".
| (But again, I digress.)
| a24venka wrote:
| Really appreciate the detailed feedback and questions! And yes,
| we'll take the website criticism as a compliment :)
|
| Good callout on the canvas navigation, we'll look into middle
| mouse button support.
|
| To answer your questions: 1) GitHub integration is on our
| roadmap. Right now you can export outputs manually but we want
| to make this seamless. 2) All your canvases are saved and you
| can search them by name in your dashboard. We're also working
| on a dedicated section for deliverables across canvases. 3) Yes
| to both! You can manually add or edit blocks, or kick off new
| agent runs that build on existing work. 4) You can currently
| only share public links of your canvas to others (but you can
| make it private at any point). We are testing out a teams
| feature which allows you to share canvases with members on your
| team securely. Beyond that, we are working on adding roles and
| email-based sharing controls which is in our roadmap. 5) Claude
| Code in a block is a really interesting idea. We don't support
| that today but we're thinking about computer use and coding
| workflows. 6)BYOK (bring your own keys) is something we've
| heard interest in and are considering. Self-hosting isn't
| available right now, though we do support private deployments
| for enterprise customers if that's ever relevant. 7) Love the
| 'preferred web browser' framing. Right now you can search
| canvases but searchable artifacts across canvases is definitely
| where we want to head.
|
| Thanks for giving it a real spin, this kind of feedback is
| incredibly valuable.
| swyx wrote:
| > And yes, we'll take the website criticism as a compliment
| :)
|
| ugh. guys. come on. stop celebrating at the 1 yard line.
| people are telling you they didnt even look at the product
| becacuse your landing page was so bad. you wasted your launch
| HN linking directly to it, ofc thats the first thing people
| are going to give feedback on. fix it right now you still
| have time.
| vivzkestrel wrote:
| excuse my memory at this point, arent there like a 100 of these
| posted on HN every month that all have something to do with multi
| agent collaboration that support 1000 models?
| visekr wrote:
| whoa congrats on the launch. lol I launched my visual canvas for
| agents today too. I went in a more of a collaborative canvas IDE,
| agent orchestration direction. But very cool to see your take on
| it
|
| https://getmesa.dev is mine
| embedding-shape wrote:
| Rather than just finding a way to link your own product, why
| don't you do the rest of us favor and provide a comparison at
| least, so it becomes a tiny bit informative instead of just
| spammy?
|
| Nothing wrong with sharing your own stuff, but at least
| contribute something back to the submission you're commenting
| on.
| poly2it wrote:
| It looks interesting, but is it really more efficient than a
| tiling window manager?
| johnyzee wrote:
| Calling it a 'canvas' makes me think that this tool is about AI
| agents doing some kind of collaborative drawing. Looking at the
| vid though, it seems more like an environment for visually
| organizing and managing agentic work (which seems very cool, and
| quite a bit more than just a canvas).
| a24venka wrote:
| Agreed. The term has been overloaded lately. We also refer to
| it as a visual workspace which perhaps captures it a bit
| better.
| useftmly wrote:
| [flagged]
| a24venka wrote:
| Great framing. You're right that context fragility is a big
| part of it. The canvas helps because each block maintains its
| own context explicitly, and connected blocks pass context
| between blocks without polluting the agents' context windows.
|
| On conflict resolution, the synthesizer block can see all
| upstream outputs, so it has full visibility into any
| divergence. It does surface contradictions to the user, though
| this is something we're constantly improving.
| jeingham wrote:
| I have not seen my final report yet for my query around
| machinist.com. However I would like to say my initial impression
| is very positive. At least in terms of the digestion of my
| somewhat nebulous request. I like the way your app was able to
| burrow down to pain points I have experienced and am trying to
| work out in terms of product market fit for the domain. I look
| forward to exploring more and giving you more feedback when I see
| the final report. I will also add that I am looking forward to
| using your product to explore other opportunities that I'm sure
| are out there in this age of AI.
| a24venka wrote:
| This is great to hear, thank you! Would love to hear your
| thoughts once you see your final report and explore some of
| those other opportunities.
| kkukshtel wrote:
| "I make AI output lots of stuff" is not an intrinsically valuable
| thing. I can run the same thing on Claude in research mode and
| get a report with cited sources in a more digestable format on my
| phone. What's the eval here on if any of this is good? Is it even
| possible to test (ie, you cant really AB test startup ideas)?
| a24venka wrote:
| Great question. The core of Spine is coordinating multiple
| specialized agents across multiple models, using the canvas to
| store and pass context selectively so each agent works with
| exactly what it needs.
|
| On the eval side, we ran Spine Swarm against GAIA Level 3 and
| Google DeepMind's DeepSearchQA and hit #1 on both.Full writeup:
| https://blog.getspine.ai/spine-swarm-hits-1-on-gaia-level-3-...
| agenticbtcio wrote:
| [flagged]
| a24venka wrote:
| Spot on. The persistence layer is a huge part of what makes the
| canvas work.
|
| For failures, we handle it at multiple levels: first, standard
| retries and fallbacks to alternate models/providers. If that
| fails, the agents look for alternate approaches to accomplish
| the same task (e.g. falling back to web search instead of
| browser use).
|
| For completeness, you can also manually re-run or edit
| individual blocks if they fail (though the agents may or may
| not consider this depending on where they are in their flow).
| ryhanshannon wrote:
| I like the overall idea and presentation. In trying it out, I hit
| the token cap before my trial task was able to complete and show
| me the end result. I'm sure your free-tier token costs are non-
| trivial but it was definitely a bummer that I couldn't even see
| one initial run's output to decide if I wanted to pay.
|
| I decided to gamble the one month fee to let it continue, but the
| payment defaulting to annual was jarring. I can see it lets you
| advertise a lower price but that only made me more tempted to
| leave altogether when I saw the price go up on the final screen.
| avree wrote:
| I got dizzy from the star effect when scrolling the website.
| throw03172019 wrote:
| Why is the landing page "paged"? Feels odd on mobile. Some titles
| are cut off because of it.
| sgallant wrote:
| This is awesome. Good job.
| maliker wrote:
| It might just be me, but this interface is the first time I felt
| the desire to interact with long-running agents even though I use
| chat interfaces all day long. Maybe it was the demo video on the
| landing page which was compelling with its examples. Maybe it was
| the feeling that I could see what was going on because I would be
| on a canvas. Nicely done!
|
| Off to keep iterating on the prototype app I started...
| a24venka wrote:
| This is really great to hear, thank you! Have fun with the
| prototype, let us know how it goes.
| jcims wrote:
| Got some great results for a rather broad domain in the first
| pass.
|
| HN is going to tend towards negative/constructive feedback, for
| me the only issue is that the mouse interaction is a bit wonky.
| Took me a minute to realize that i could select different mouse
| modes. With that I'd say I'd echo TheTaytay's comment about mouse
| interaction and for me generating docx (which was the output of
| my agents, haven't even explored explicitly asking for something
| else) creates a bit of a barrier to use the content for me.
| Markdown or even HTML would be helpful.
|
| But these are just minor nits, love the concept and great
| execution.
| varenc wrote:
| Quick feedback about your demo video: I generally quite liked it
| and it really helped me understand Swarm. Two thoughts:
|
| - you lament the chat interface, but the first 1m30s of the video
| I only see the chat interface
|
| - your research task is LLM/AI related. There were moments where
| I found this slightly confusing and I wasn't sure if I was
| reading about Swarm itself or just its own research. Would
| recommend something non-LLM related and more generally applicable
| for the demo video.
|
| Very cool!
| a24venka wrote:
| Thanks for the feedback! On the chat interface point, we
| actually think chat is still a great way to get into the
| product, but we leverage the canvas behind the scenes to let
| the agents do better work and give users the ability to audit
| and visualize what's happening. Good note on the demo topic
| though, we have some broader, non-AI demos coming soon on our
| website and newsletter.
| orky56 wrote:
| Congrats on the launch. Few pieces of feedback that are similar
| in nature to what has already been shared but unique in terms of
| solutions.
|
| 1) The chat interface as shared in the video is a prime starting
| point to capture intent but anchors viewers to what Spine is all
| about. Try a show-tell-show approach where you can demonstrate
| (ideally above the fold) a compelling output, credits used and
| agents leverages, and THEN the simple prompt used to get it all
| started. Let's be real: the chat interface is not the a-ha
| moment. It's what you get out of it, the orchestration that
| happens behind the scenes, and finally the familiar chat
| interface that kicks it all off.
|
| 2) Who is the target persona for this? The benchmark accolade is
| great for the technical audience but they may not care about
| doing everything in the browser. The non-technical audience may
| like the browser but prefers examples of other companies and use
| cases are make the technical more accessible. The board concept
| helps the abstraction layer of understanding what is produced by
| the agents but the missing piece is memorializing the decision-
| making where human in the loop needs something to grasp & share.
| a24venka wrote:
| Really appreciate the detailed feedback.
|
| 1) Agreed on the show-tell-show framing: Chat is a natural
| starting point for people frustrated with linear interfaces,
| but you're right that the a-ha is the orchestration and
| outputs. We'll keep this in mind as we build out our gallery
| and demos going forward.
|
| 2) Right now our primary users are knowledge workers and
| researchers who need to do complex, multi-step work. The
| benchmarks help establish credibility, but we're building out
| more use case demos and a gallery to make it tangible for a
| broader audience. On the human-in-the-loop point, the agents do
| pause and come back to the user, and there is scope for
| iterations as well, but we haven't highlighted this well
| enough. We'll do a better job of showing that going forward.
| nanookclaw wrote:
| To your question about how others approach multi-step AI work
| beyond coding: I run an autonomous agent on OpenClaw that handles
| multi-day projects through structured state files and round-robin
| work loops. No visual canvas, but the same core pattern you
| discovered -- externalizing context to persistent storage instead
| of holding it in memory.
|
| The agent writes intermediate results to JSON state files and
| markdown logs between sessions. Each new session reads state from
| disk, picks up where the last one left off, and writes results
| back. Context never degrades because it is never held in a
| context window across boundaries -- it is always reconstructed
| from structured files.
|
| What breaks first: concurrent writes. When multiple cron-
| triggered sessions modify the same state file, you get race
| conditions. Your canvas model likely handles this more gracefully
| since blocks have defined ownership. For flat files the solution
| has been build locks and TTLs, which works but feels like
| reinventing what a proper DAG execution engine gives you for
| free.
|
| The other thing that resonated: agents running longer when they
| delegate to blocks. Same pattern -- my agent runs 58-minute work
| sessions and stays productive because it offloads all state to
| disk. The agent itself is stateless between sessions. The
| workspace IS the memory.
___________________________________________________________________
(page generated 2026-03-13 23:00 UTC)