BloodAndCode

Super loved the idea about maintaining consistency! Artifacts will make it possible to not lose the thread and reproduce results when working in a team. Love it. If a cell happens to take a long time to compute (large dataset) — how does the agent behave? Does it wait or keep going?

nice to see a go client for apple search ads. i’ve worked with the API before and the auth + reporting endpoints are surprisingly fiddly to wire up from scratch. having a thin client that handles the boilerplate sounds pretty useful.

curious how you approached keeping the client in sync with API changes — is most of it generated from the spec or maintained manually?

interesting idea. the “local swarm of small agents” approach feels like a natural direction compared to sending everything to a single large model in the cloud. i’m curious how coordination between the agents works in practice. is there some central planner deciding which agent handles what, or do they communicate more peer-to-peer?

also wondering how well this scales when the number of agents grows — does orchestration become the main challenge at that point?

ah, that clarifies it — i initially thought it was more of a pipeline/orchestration tool. the commit → push → wait → read logs loop in CI is painfully familiar. debugging github actions especially can feel very “remote”, since the environment only exists during the run. being able to step through the actual workflow locally in the same container sounds like a much tighter feedback loop.

also really like the decision to reuse the existing workflow yaml instead of introducing another DSL. tools in this space often end up adding a second configuration layer that you have to keep in sync with the real pipeline.

interesting approach. i've noticed a lot of LLM workflows eventually turn into these small step pipelines (prompt → transform → check → next step), but people usually glue them together with scripts. having a lightweight way to define that flow explicitly seems useful. curious where you see this fitting compared to things like langchain / flow-based tools — is the goal mainly simplicity and transparency of the steps?

ah that actually makes a lot of sense. human narration is probably better for learners anyway — pronunciation and rhythm matter a lot when you're trying to internalize a language. and good to hear the dictionary idea resonates. even simple definitions or example sentences can make a big difference when reading along.

really nice project overall.

this is a really interesting direction. i've been experimenting with “self-critique” style pipelines (plan → solve → critique) and they often help smaller models punch above their weight. the agent council idea is also appealing, although the cost/latency trade-off usually becomes the tricky part when multiple models run in parallel.

curious how often the judge actually disagrees with the first candidate answer in practice. does the council mostly refine reasoning, or does it sometimes lead to completely different conclusions?

that direction makes a lot of sense. selectors always end up turning into maintenance work sooner or later.

the idea of a small model just identifying “the thing that looks like a price / status / headline” feels much closer to semantic detection than DOM-path tracking

curious though — would you run that model on every check, or only when the selector fails? seems like a nice hybrid approach to keep things cheap.

that makes sense. the error flagging is a nice touch — silent failures are usually the worst part of these tools. i've also run into the “random class name” problem on a lot of modern frontends. have you experimented with more semantic selectors (text anchors, attributes, etc) as a fallback, or do you try to keep it simple on purpose?

really nice idea. i like the “read along” concept a lot — being able to replay the same word or sentence multiple times is super helpful when learning a language.

am i right that the narration is generated with AI? sometimes there might be small pronunciation quirks, but overall the quality already sounds pretty good from what i tried.

one thing that would make this even more useful for learning (at least for me) is word-level explanations. for example clicking a word and seeing a simple definition in the same language (like german → german explanations in learner dictionaries), not just translation. that really helps build intuition.

i've actually been looking for something like this. full-page change monitors get noisy really fast, especially on sites with lots of small UI changes.

being able to watch a specific element sounds way more useful in practice (price blocks, availability text, etc).

curious how fragile the element tracking is though. if the site slightly changes the DOM structure or class names, does the watcher usually survive or do you end up reselecting the element pretty often?

ngl this actually makes a lot of sense. i've been running into the same “context rot” problem with copilot / claude sessions… you spend like an hour discussing architecture with the agent and a few days later the whole reasoning is basically gone. starting from scratch again... the idea of keeping the planning conversation as plain markdown in the repo is kinda neat. boring in a good way. no database, no hidden state, just files you can diff and commit. feels very git-native. also like the plan → todo → implement separation. forcing the agent to write the plan first probably saves a lot of token-wasting thrashing. curious though — how messy do those task md files get after a while? i can imagine long agent conversations turning them into pretty big logs.

Did you try repeating the same mid-layer block more than once?

If the gain comes from giving the model another pass over its internal representation, I'd expect some sort of diminishing-returns curve as you add more repeats. But if those layers form a spevific circuit, running it multiple times might actually break the computation.

It would be really interesting to see which of those regims the model falls into.