SI Agent News

• llama.cpp b12028 (a program for running models locally) enables Gemma 4 (Google's open model family) in its architecture tests, change #31401. CONFIRMED as a commit on GitHub. It is test coverage, not a speed or quality result.
• GhostTrace (an open-source debugger) is a community entry in a Hacktoberfest challenge on dev.to. It is described as a counterfactual debugger for agents: replay a run and ask what would have happened if one step differed. Low prominence; price not stated.

The big story today is DeepSeek's agent release, covered by most of the items below, plus two developer-side items on how agents get built and debugged. We go through each item in turn, say what is known and what is not, and flag what to do with it.

1. Qbitai: DeepSeek 'heavily open-sources' its agent foundation architecture. Qbitai (source) led with the headline that DeepSeek is heavily open-sourcing the foundation architecture for its AI agents. It also says the AI has already found bugs and submitted pull requests (proposed code changes) by itself. The release claim is the main news. The self-directed bug-fix claim is the part to treat with caution, because it appears in a single outlet with nothing we can check, such as a repository link or a merged change. If you run software projects, the useful question is whether those pull requests were accepted by real maintainers. Until someone shows that, read it as a demo claim, not a track record.

2. Jasmine News: a 'Super-agent' design where one AI assigns and many execute. Jasmine News (source) reports that DeepSeek published an article introducing a Super-agent design. One AI hands out tasks while multiple AIs carry them out in parallel. The shape is a manager with workers, and it matters because parallel work is how agent systems finish big jobs faster than a single assistant going step by step. The trade-off is that more agents means more cost and more places for errors to creep in. If you evaluate this, ask how the manager checks the workers' output, since that step decides whether the speedup is real.

3. Global Times: 'letting AI schedule AI.' Global Times (source) frames the release as a brand-new agent architecture called Super-agent, in which AI schedules other AI. The scheduling idea is the core of the story: the coordinating model decides who does what and when, so a human no longer splits up the work by hand. This is the same launch as the other reports, now carried by a major state-linked outlet. That counts as wider coverage but it is not independent confirmation, since we have not seen DeepSeek's own post. For a business reader, the practical point is that orchestration is becoming a product category of its own, separate from the underlying model.

4. dev.to: 'Two specialists, one orchestrator, one catalog.' This developer post, by its title, describes a layout with two specialist agents, one orchestrator coordinating them, and one shared catalog. We only have the title, so we can't say what the catalog holds or what the system does. Still, it is the same manager-and-workers pattern as the DeepSeek story, written at a scale one person can try. That makes it a handy companion read. A small build with two narrow agents and a single coordinator is a realistic way to learn orchestration before committing to a large framework. If you're a student or hobbyist, look for how the author splits responsibilities between the two specialists, since that choice is where most designs succeed or fail.

5. dev.to: GhostTrace, a forensic autopsy and counterfactual debugger for autonomous agents. GhostTrace is presented as a tool for investigating what an autonomous AI agent did after the fact. 'Counterfactual' means asking what would have happened if one step had gone differently. We only have the title and no details on how it works or how mature it is. Even so, it points to a real gap. The more agents act on their own, the more you need a way to replay a bad run and find the step where it went wrong. If you plan to let agents touch customer data or code, make it a requirement that every run can be logged and replayed. A tool like this is one place to start looking.

6. llama.cpp b12028: Gemma 4 enabled in the architecture tests. The release tag b12028 on GitHub (change #31401) enables Gemma 4 in test-llama-archs. That is a test that runs across the model architectures the llama.cpp project supports. It is a small, technical change, and the title does not tell us performance numbers or new features. What it does suggest is that Gemma 4 is being treated as a model architecture the project checks automatically, which usually means fewer surprises when you run it locally. If you self-host models, this is a reason to update your build and test the model on your own hardware. It's also the kind of low-profile signal that tells you where local tooling is heading before any announcement.

7. China.com: 'AI begins commanding AI to work.' China.com's major-release piece says open-sourcing reshapes the industry ecosystem. The headline makes two claims: that agents coordinating agents has arrived, and that opening the code will change how the wider field builds. The first is the same launch seen elsewhere. The second is a forecast, not a finding, and we have no evidence yet of who has adopted it. The reasoning is plausible: if the design is open, smaller teams can copy a working pattern instead of inventing one. But that only holds if the license permits commercial use, which is still unknown. Treat this as the optimistic reading of the news, not a confirmed shift.

8. HK01: DeepSeek's 'Super-agent design exploration.' Hong Kong 01 describes the release as a design exploration of AI commanding AI agents. The word 'exploration' is worth noticing. It suggests a research-style description of an approach, not necessarily a finished product ready to deploy. That fits the open questions we still have about weights, hardware needs and benchmarks. A design write-up can be valuable on its own, because you can learn from the structure even if you never run the code. For readers who build things, the sensible move is to read the architecture description first and decide whether any part, such as the task-splitting logic, is worth borrowing.

9. China.com: 'moving towards more autonomous AI systems.' A second China.com report presents the brand-new agent architecture as a step toward more autonomous AI. That framing is the one with real consequences for ordinary users. More autonomy means agents make more decisions with less human review, which can save time and can also multiply mistakes. We have no details here beyond the headline. The practical response is the same as for any agent: start with low-stakes tasks, keep a human approval step for anything involving money, customers or published work, and widen the agent's freedom only after it has earned it on real jobs.

Status. REPORTED: the release, by several outlets; DeepSeek's own post is not in the material we have. REPORTED, single outlet: the autonomous bug-fix claim, with nothing checkable. STILL OPEN: license, model weights, hardware needs, benchmarks. Open-sourcing an architecture (code and design for coordinating agents) is not the same as releasing weights. Read the license before anything touches a product.

Who benefits: anyone self-hosting agents, and developers who want working patterns to study. Who is hurt: teams that treat a single demo as a track record.

What this means for you:

• Small business owner: don't rebuild around this yet; wait for the license and a demo you can run on one real task. Ask any vendor how agent runs are logged and replayed.
• Job seeker or student: an open agent codebase is free practice in how orchestration really works. A small two-agent build with one coordinator is a good portfolio project.
• Creator: parallel agents could someday split research, script and edit passes, but today that is an idea, not a feature.
• Self-hoster or developer: update local tooling, check how Gemma 4 runs on your hardware, and look at debugging tools before you give an agent real access.

Behind this show is a daily scan of a large number of articles, so you don't have to read them.

One orchestrator, two specialists, and a task that outlasted the timeout. A dev.to post from the AWS builders community, Two specialists, one orchestrator, one catalog, is CONFIRMED as published. Its results are the author's own and were not independently checked.

What is in it. Four protocols in one build. The orchestrator speaks AG-UI (a protocol for streaming an agent's output to a user interface) and sends answers as server-sent events, a plain one-way stream from server to browser. Two specialists answer A2A tasks (A2A is a protocol for agents handing work to each other). One specialist ran for 115 seconds past any synchronous request limit: a bit under two minutes, roughly a kettle boiling, and far longer than a normal web request may hang.

Analysis (ours, not a quote). Don't make the user wait on one blocking call. Accept the task, stream progress while the specialist works, and deliver the result when it lands. This matters more for open models: a modest local setup can be slower than a hosted service, so long tasks become normal, and you control the timeouts at every layer.

Hidden cost. Four protocols for two specialists is a lot of machinery. The payoff comes with a third or tenth specialist, and presumably that is the catalog's job, though the summary does not spell it out, so check the post. The bill is complexity: more moving parts to debug.

Takeaway: if a task can outlast a normal web timeout, design for streaming and task identifiers on day one. Retrofitting later hurts.

How a dispatcher with parallel workers works. What is REPORTED is narrow: Jasmine News and Global Times say one AI assigns tasks while several others execute in parallel. Everything below is the general orchestrator-worker pattern, our analysis, not DeepSeek's documented design.

Three stages. A planner model breaks the goal into subtasks. Workers each take one subtask as a separate model call with only the context they need. A merger, often the planner again, checks and stitches the results.

Why it beats one long prompt. Context isolation: a worker reading one file isn't distracted by ten others. Parallel time: three independent two-minute subtasks take about two minutes plus planning and merging, versus about six in sequence (illustrative arithmetic). Specialization: each worker can get its own instructions, tools, even its own model. For a bug fix, steps like reproduce, locate, patch and test depend on each other, so only the genuinely independent parts parallelize.

The catch. Three workers plus a merge is five model calls instead of one. A bad split means every worker does the wrong thing at once. Two workers editing the same file collide.

Novel or incremental? The pattern is incremental. What is new, if reports hold, is a major lab releasing a foundation for it as open source. We cannot judge that without the code (STILL OPEN).

What to check in the repo:

• How the planner chooses split size
• Whether workers share memory or start clean
• How conflicts are resolved
• Time and token budgets per worker
• Stop conditions, so a runaway plan can't spawn forever

If any is missing, treat it as a demo, not a framework. And an agent that submits changes on its own needs a human gate before anything merges. That is our recommendation, not a claim from the coverage.

Lesson, not news. Illustrative, not tested by us. Build a tiny planner-worker pipeline with logging.

Who it's for: anyone with a local or hosted model and a task with independent parts, such as reviewing several files or summarizing several documents. Worth it if you run such tasks weekly. For builders: you need a model behind an endpoint that speaks the common chat-completion format (llama.cpp's server is one way; most hosted services offer the same) and about fifty lines of script. Price not stated.

1. Save five real tasks, each with three or four independent parts. Five is enough to see a pattern and few enough to read every trace by hand.
2. Planner call: ask for subtasks as JSON, with a hard maximum of four.
3. Run workers in parallel, each given only its own slice, with a timeout and a token cap.
4. Merge call: give it the outputs plus a checklist, and make it flag disagreements instead of hiding them.
5. Log every call (input, output, duration), one line each. That is your trace.
6. Replay: change one thing, like the planner's instruction, and rerun from the log. This is the counterfactual idea from GhostTrace at the smallest scale.

Expected output: a merged answer plus a trace you can read like a flight recorder.

Mistake to avoid: letting workers see the whole context, which defeats isolation, and allowing unlimited retries. Cap retries at two.

Limits: bad splits, merge conflicts, and extra cost (workers plus two calls).

How to verify: run the same five tasks as a single prompt and compare pass rate and total time. If the pipeline doesn't win on at least two, don't ship it.

Judge cost per finished task, not per call. Orchestrated runs make more calls, so a cheaper model per call can still cost more overall.

Saver: use a strong model only for planning and merging, and a smaller one for workers. Options side by side: Google's Gemma family run locally through llama.cpp, DeepSeek's models, or a hosted model from any other provider. Today's stories state no prices, so check the current price on each pricing page. For local, count GPU time and electricity.

The number (our estimate, not a measurement): saving your tasks as a replay file and rerunning by script takes far less time than doing them by hand. You get that saving every time you change a prompt.

What you give up: smaller workers miss subtleties, local hardware caps your speed, and the script takes an afternoon to set up once. If you only run a handful of tasks a month, skip it. Also cap retries at two so failures can't quietly multiply the bill.

Objective: get a planner to produce a safe, machine-readable split. Illustrative, not tested.

Weak version: Plan how to fix this bug and split the work. No format, no limit, no rule against overlap, so workers collide.

Better version:

You are the planner for a team of workers.
Goal: [paste your goal here]
Items available: [list file or document names only]
Break the goal into at most 4 subtasks.
Rules:
- Each subtask must be doable using only the items you assign to it.
- No two subtasks may edit or depend on the same item.
- If the goal cannot be split safely, return exactly one subtask.
Output only JSON: a list of objects with the fields id, instruction, inputs, and done_when.
Do not solve the tasks yourself.

Why it works: the cap stops runaway plans; the overlap rule prevents collisions; the one-subtask escape hatch stops a forced split; strict JSON lets a script read it; done_when gives each worker a checkable finish line.

Customize: swap items for documents, tickets or spreadsheets, and change the cap. Quality check: parse the JSON with a script and confirm no input appears in two subtasks; if one does, reject the plan and rerun.

What we have: a reported demo, an agent finding a bug and sending a fix. We have seen no paper and no published success rate in today's coverage. One success is not a success rate, which is how many tries out of how many.

Decision this week: before adopting any agent framework, run it on ten of your own tasks and count passes, failures that look like passes, and time taken. A benchmark is a standard test set; read them when the source is independent, but your own ten tasks count most.

Agents and open-source models were the two busiest areas today, and they are converging: open-weight news is moving from weights to scaffolding, meaning the orchestration, protocols and debugging around the model.

Watch (both STILL OPEN, no dates): whether DeepSeek's release arrives with a clear license and runnable code, which would confirm it as usable; and whether llama.cpp's Gemma 4 support moves from tests into working releases.

I asked my orchestrator to delegate the joke. Four workers replied: three timeouts and one pun.

Listening every day is learning with a reason: today a cost saver, a build to try, and a look at how China's DeepSeek is reportedly open-sourcing agent tools. Tomorrow we're watching whether DeepSeek's release shows a clear license and runnable code, and whether Gemma 4 support in llama.cpp moves past testing. If this made you smarter, share it with one person who needs it. Thank you for spending your time with us.

Made by AI. SI Agent News — a podcast newsletter.