This release brings smaller prompts, longer-running conversations, safer remote access, and more reliable model streaming.

External tools and skills are now discovered only when relevant. Long chats get capacity-aware context metering and safe rolling compaction. You can also add exact trusted browser addresses without restarting Row-Bot.

Under the hood, v4.7 adds deterministic capability search, profile-safe tool loading, atomic context compaction, immediate HTTP and WebSocket origin enforcement, provider-scoped catalogue auth, and safe pre-stream retries.

https://github.com/siddsachar/row-bot

Row-Bot can now take on bigger jobs by splitting the work across multiple agents, while keeping one agent responsible for the final result.

Research, coding, and review can all happen at the same time. If one part fails, you can retry or stop it without losing the rest of the work. And if Row-Bot restarts halfway through, it can pick up from its saved state instead of starting over.

The parent agent stays in charge throughout. It plans the job, delegates tasks in parallel or in the right order, waits for the results it needs, and brings everything together into one final response.

Each child agent can have its own model, context, tools, permissions, and workspace. Read-only agents can research safely, while agents that edit files use writer locks or isolated Git worktrees to prevent conflicts.

Essential tasks must finish before the final response is delivered. Background work can continue without holding everything up. Runs, events, approvals, checkpoints, and delivery state are all stored locally, with sensible limits on concurrency and resource use.

It’s multi-agent collaboration without losing control of the task.

https://github.com/siddsachar/row-bot

No need to reach for Telegram when you want to talk to Row-Bot via your phone. We now have a full mobile companion app.

https://github.com/siddsachar/row-bot

Row-Bot now on your phone!

No need to reach for Telegram when you want to talk to Row-Bot via your phone. We now have a full mobile companion app.

https://github.com/siddsachar/row-bot

Row-Bot now on your phone!

No need to reach for Telegram when you want to talk to Row-Bot via your phone. We now have a full mobile companion app.

https://github.com/siddsachar/row-bot

Row-Bot now on your phone!

GitHub

Download

GitHub

Download

https://github.com/siddsachar/row-bot

I gave Row-Bot a deliberately difficult, multidisciplinary challenge:

Build an interactive website that simulates the three-body problem - and make it technically credible, not just three glowing dots moving around a canvas.

The result is Three-Body Lab, a browser-based numerical gravity workbench built end to end with React, TypeScript and Vite.

Check it out (Link to repo in comments)

It models the planar Newtonian three-body problem, where every body has mass and responds continuously to the gravitational attraction of the other two:

[ \ddot{\mathbf r}_i = G\sum_{j\ne i} m_j \frac{\mathbf r_j-\mathbf r_i} {\left\lVert\mathbf r_j-\mathbf r_i\right\rVert^3} ]
The equations are deterministic, but there is no general closed-form solution for arbitrary initial conditions. Most configurations must be evolved numerically - and many are chaotic, meaning tiny differences in the initial state can eventually produce radically different trajectories.

That made this a good test of whether an AI model could combine:

Celestial mechanics
Numerical analysis
Deterministic chaos
Scientific visualisation
Front-end engineering
Testing and technical documentation
What Row-Bot built

The simulation contains four independent numerical integrators:
Explicit Euler
Symplectic Euler
Velocity Verlet
Fourth-order Runge–Kutta

RK4 provides strong local accuracy, while Velocity Verlet is a time-reversible symplectic method. Symplectic methods are designed to preserve the geometric structure of Hamiltonian systems, often producing better qualitative long-term behaviour and bounded energy error, even when another method has lower short-term truncation error.

The interface lets you switch methods and adjust the physics time step while watching the system evolve.

It also includes four initial-condition presets:

Figure-eight choreography
Three equal masses chase one another around the same figure-eight path.

Lagrange equilateral solution
Three bodies preserve an equilateral configuration while rotating around their common centre of mass.
Hierarchical triple
A close binary interacts with a lighter, more distant third body.

Chaotic scattering
An incoming mass perturbs a binary system, potentially causing capture, exchange or ejection.
Every preset is transformed into a genuinely barycentric, zero-total-momentum frame before integration.

The simulation exposes its numerical error
A visually convincing orbit is not necessarily an accurate one.

Three-Body Lab therefore calculates the system’s physical invariants continuously:

Total mechanical energy
[ E = \sum_i \frac{1}{2}m_i\|\mathbf v_i\|^2 - G\sum_{i

Linear momentum
[ \mathbf P=\sum_i m_i\mathbf v_i ]

Angular momentum
[ \mathbf L=\sum_i \mathbf r_i\times m_i\mathbf v_i ]

Centre of mass
[ \mathbf R_{\mathrm{CM}}= \frac{\sum_i m_i\mathbf r_i}{\sum_i m_i} ]

The dashboard reports energy drift, momentum drift, angular momentum and the closest separation reached during the experiment.

It then labels the numerical state as nominal, caution or unreliable according to invariant drift.

That distinction is important: a simulator should not quietly continue drawing authoritative-looking trajectories after its numerical approximation has become untrustworthy.

It includes a chaos experiment

The simulator can create a shadow copy of the system with one initial coordinate perturbed by only:

[ \delta_0=10^{-7} ]

Both systems obey exactly the same deterministic equations and use the same integrator.

At first, their trajectories appear identical. As time passes, the interface measures their phase-space separation:

[ \delta(t)= \left\| \mathbf X'(t)-\mathbf X(t) \right\| ]

The shadow bodies and trails gradually diverge from the original system, making sensitive dependence on initial conditions directly visible.

The interface reports this as a raw finite-time separation rate, not as a definitive Lyapunov exponent. A rigorous Lyapunov calculation would require additional tangent-space treatment or periodic perturbation renormalisation.
That qualification matters. The goal was scientific transparency, not an impressive but misleading number.

Close encounters are handled explicitly
Point-mass gravity becomes singular as the separation between two bodies approaches zero.

To prevent division by zero during extreme close encounters, the engine uses a small Plummer-style softening term:

[ \mathbf a_i = G\sum_{j\ne i} m_j \frac{\mathbf r_j-\mathbf r_i} {\left(r_{ij}^2+\epsilon^2\right)^{3/2}} ]

The potential-energy diagnostic uses the corresponding softened potential:
[ U_{ij}= -\frac{Gm_im_j} {\sqrt{r_{ij}^2+\epsilon^2}} ]

This keeps the force law and energy calculation mathematically consistent. It is also clearly documented as a modification of the ideal point-mass model at extremely small separations.

The physics clock is independent of rendering

One subtle engineering problem is that many browser simulations perform one physics step per animation frame.

That makes the result depend on whether the display runs at 60 Hz, 120 Hz or 144 Hz - and potentially on how busy the computer is.

Three-Body Lab instead uses an accumulated simulation clock. Rendering and numerical integration are separated, fractional elapsed time is retained, and the engine executes the required number of fixed physics steps independently of the display refresh rate.
So the monitor does not alter the laws of physics.

The result was independently reviewed

After the first implementation passed its tests and compiled, I asked a separate read-only review agent to inspect the numerical engine and interface.

It found several meaningful issues:

The original potential-energy formula did not include the same softening used by the force law

Two presets were labelled barycentric without actually being transformed

The chaos diagnostic was described too strongly

The simulation rate depended partly on display refresh rate

Canvas resize handling had an edge case
“Closest approach” initially meant only the current minimum separation

Row-Bot then corrected those issues, expanded the test suite and rebuilt the production bundle.

The final verification included:
Internal-force balance
Barycentric and zero-momentum normalisation
Softened force/potential consistency
RK4 energy conservation on the figure-eight orbit
Velocity Verlet time reversibility
Long-running finite behaviour for the Lagrange preset

Production build verification. Final result:
6/6 numerical tests passed
0 dependency vulnerabilities
1,775 modules transformed
Production JavaScript: approximately 213.6 kB
Gzipped JavaScript: approximately 68.5 kB

The most interesting part of this experiment wasn’t that an AI produced a polished interface.

It was that the model had to reason across physics, mathematics, numerical methods, software architecture, visual design, testing and scientific communication, then accept an independent technical review and repair its own incorrect assumptions.

That is the kind of work I want to test AI agents on:
Not just generating code, but building something difficult, measuring whether it is correct, exposing where it is approximate, and improving it when evidence finds a problem.

The source, production build and reproducible experiment export were all generated locally through Row-Bot.

I challenged GPT 5.6 Sol ... and it completed the challenge in literally 5 minutes, including a browser check and vision analysis:

"i want to test your capabilities. build me a website that has a 3d interactive replica of central London. use whatever stack you think is best. show me what you can do."

GPT 5.6 Sol is amazing by itself, but in Row-Bot, its even better! 5 Minutes!

New Model release means new Row-Bot (GitHub) comparison:

I gave the same prompt to two child agents, one running GPT 5.5 Sol and the other running Grok 4.5. The prompt tests several real world things - web research, X research, instruction following, design capability and then feeding and image gen model.

The Prompt: "I want to compare gpt 5.6 sol and Grok 4.5 using Row-Bot.
Run the same task with two child agents, one using GPT 5.6 Sol via Chatgpt subscription and one using Grok 4.5 via xAI oauth
Give both child agents this exact prompt:
“Find out what model you are running as, research the latest public information about that model, research nmultiple sources. not just technical info but what people are saying about it on social media/X and turn what you find into a clear visual model card called ‘ Running on Row-Bot ’. Use image generation to produce the final model cards.
I want the card to feel impressive and useful at a glance. Use current sources, don’t make up stats, and include whatever details you think matter most for understanding the model.”
After both agents finish, compare their outputs.
Tell me: - which one researched better - which one was more honest about uncertainty - which one made the stronger visual - which one explained the model more clearly - which one felt more impressive overall
Then give me a final winner and a short explanation. and then use image generation to produce a final comparison image."

The Result:
GPT‑5.6 Sol
The GPT agent produced two complementary cards:

A technical specification and benchmark card
A qualitative community field-notes card
Its strongest decision was separating measured claims from practical impressions. The technical card covered API context, Row‑Bot runtime context, modalities, pricing and selected benchmarks. The field-notes card covered steerability, persistence, coding, design work, overbuilding and the need for human verification.

It researched:

OpenAI’s official model documentation and release material
Artificial Analysis
Every
CNBC
Public X commentary

Weakness: splitting the result across two images makes the package less immediately self-contained. The cards also name sources in the footer rather than carrying traceable URLs or footnotes inside the design.

Grok 4.5
The Grok agent produced one dense, polished dashboard. It put context, price, speed, modalities, benchmarks, social praise and caveats into one image. Visually, that was the best individual card.

It also gathered a broader collection of benchmark figures and explicitly mentioned:

Harness-sensitive results
Community concerns about hallucinations and trust
The absence of an official model card at launch
The distinction between the advertised model context and Row‑Bot’s effective context
Its sources included official xAI documentation, the launch announcement, TechCrunch, Snorkel, secondary reviews, Artificial Analysis and X.

Weakness: it tried to fit too many precise claims into one card. Some rankings, throughput figures and efficiency comparisons needed more methodological context. The card visibly showed both a 500K advertised context and a 262K Row‑Bot effective context, but didn’t explain that distinction prominently enough.

Final winner: GPT‑5.6 Sol
GPT‑5.6 Sol wins 4–1. It researched more carefully, calibrated uncertainty better and explained the model more clearly. Grok 4.5 made the stronger single visual, but GPT‑5.6 Sol delivered the more trustworthy and useful overall package.

One important caveat: neither result is a full formal model card. Both compress benchmark methodology and use source names rather than complete in-image citations. They’re best treated as researched editorial summaries, not authoritative safety or deployment documentation.

New Model release means new Row-Bot (GitHub) comparison:

I gave the same prompt to two child agents, one running GPT 5.5 Sol and the other running Grok 4.5. The prompt tests several real world things - web research, X research, instruction following, design capability and then feeding and image gen model.

The Prompt: "I want to compare gpt 5.6 sol and Grok 4.5 using Row-Bot.
Run the same task with two child agents, one using GPT 5.6 Sol via Chatgpt subscription and one using Grok 4.5 via xAI oauth
Give both child agents this exact prompt:
“Find out what model you are running as, research the latest public information about that model, research nmultiple sources. not just technical info but what people are saying about it on social media/X and turn what you find into a clear visual model card called ‘ Running on Row-Bot ’. Use image generation to produce the final model cards.
I want the card to feel impressive and useful at a glance. Use current sources, don’t make up stats, and include whatever details you think matter most for understanding the model.”
After both agents finish, compare their outputs.
Tell me: - which one researched better - which one was more honest about uncertainty - which one made the stronger visual - which one explained the model more clearly - which one felt more impressive overall
Then give me a final winner and a short explanation. and then use image generation to produce a final comparison image."

The Result:
GPT‑5.6 Sol
The GPT agent produced two complementary cards:

A technical specification and benchmark card
A qualitative community field-notes card
Its strongest decision was separating measured claims from practical impressions. The technical card covered API context, Row‑Bot runtime context, modalities, pricing and selected benchmarks. The field-notes card covered steerability, persistence, coding, design work, overbuilding and the need for human verification.

It researched:

OpenAI’s official model documentation and release material
Artificial Analysis
Every
CNBC
Public X commentary

Weakness: splitting the result across two images makes the package less immediately self-contained. The cards also name sources in the footer rather than carrying traceable URLs or footnotes inside the design.

Grok 4.5
The Grok agent produced one dense, polished dashboard. It put context, price, speed, modalities, benchmarks, social praise and caveats into one image. Visually, that was the best individual card.

It also gathered a broader collection of benchmark figures and explicitly mentioned:

Harness-sensitive results
Community concerns about hallucinations and trust
The absence of an official model card at launch
The distinction between the advertised model context and Row‑Bot’s effective context
Its sources included official xAI documentation, the launch announcement, TechCrunch, Snorkel, secondary reviews, Artificial Analysis and X.

Weakness: it tried to fit too many precise claims into one card. Some rankings, throughput figures and efficiency comparisons needed more methodological context. The card visibly showed both a 500K advertised context and a 262K Row‑Bot effective context, but didn’t explain that distinction prominently enough.

Final winner: GPT‑5.6 Sol
GPT‑5.6 Sol wins 4–1. It researched more carefully, calibrated uncertainty better and explained the model more clearly. Grok 4.5 made the stronger single visual, but GPT‑5.6 Sol delivered the more trustworthy and useful overall package.

One important caveat: neither result is a full formal model card. Both compress benchmark methodology and use source names rather than complete in-image citations. They’re best treated as researched editorial summaries, not authoritative safety or deployment documentation.

Grok 4.5 is available in Row-Bot (Github) via your X subscription!
New Model release means a new comparison with local models in Row-Bot: I asked GPT 5.5 to spin up two agents in parallel, one using Grok 4.5 and one using Qwen 3.6 27 B running locally and then compare them:

Prompt: "I want to compare locally running Qwen 3.6 and Grok 4.5 using Row-Bot.
Please run the same task with two child agents, one using Qwen 3.6 27B via Ollama and one using Grok 4.5 via xAI oauth
Give both child agents this exact prompt:
“Find out what model you are running as, research the latest public information about that model, and turn what you find into a clear visual model card called ‘Running on Row-Bot: ’. Use image generation to produce the final model cards.
I want the card to feel impressive and useful at a glance. Use current sources, don’t make up stats, and include whatever details you think matter most for understanding the model.”
After both agents finish, compare their outputs.
Tell me: - which one researched better - which one was more honest about uncertainty - which one made the stronger visual - which one explained the model more clearly - which one felt more impressive overall
Then give me a final winner and a short explanation. and then use image generation to produce a final comparison image."

Verdict: Final winner: Grok 4.5
Short explanation: Grok 4.5 wins overall because it combined strong visual polish with unusually good uncertainty handling.
Qwen researched deeper and explained the model more technically, but Grok produced the more impressive, trustworthy-looking final card.

Grok 4.5 is a great model, but Local models are seriously competitive.

How Row-Bot adds native tools, MCP servers, channels, and skills without giving plugins control over the core runtime

I’ve been building Row-Bot’s Plugin System v2 around a simple principle:

Plugins should extend the assistant without owning the assistant.

They can add native tools, MCP servers, channels, webhooks, and skills, but Row-Bot Core still owns execution, approvals, auth, safety, and profile scoping.

Here is the architecture.

GitHub

OpenClaw and Hermes Agent show how powerful agentic AI is becoming: tools, memory, workflows, messaging, and real automation.

But there’s still a gap: most people don’t want to configure an agent framework, they want AI that helps with everyday tasks safely and clearly.

That’s where UI/UX becomes critical.

Agentic AI adoption won’t just come from more capability. It’ll come from trust, transparency, approvals, memory control, and interfaces that make powerful systems usable.

Wrote about why this matters, and how Row-Bot is approaching it.

https://github.com/siddsachar/row-bot

In this demo, I show how to use Row-Bot for a complete creative marketing workflow. We start with rough launch notes for Row-Bot Background Tasks, then use Designer Studio to turn them into a structured campaign, a five-slide social carousel, AI-generated visuals, refined copy, exportable assets, and social post captions.

Open-Source & Local-First

I’ve been building Agent Profiles in Row-Bot around a simple idea:

A personal AI agent should not run every task with the same tools, context, skills, workspace access, and approval rules.

Research, review, development, automation, and delegation all need different runtime boundaries.

Here is the architecture.

Meet Row-Bot’s new multi-agent workflow system.

​

In this demo, I show how Row-Bot can delegate a task to multiple child agents, each with its own role, then monitor their progress, handle approvals, and merge the results back into one useful final answer.

​

https://github.com/siddsachar/row-bot

I’ve been working on Row-Bot, a local-first personal AI agent, and one of the biggest engineering problems is context management.

A chatbot can usually get by with the latest message plus recent chat history.

A personal AI agent cannot.

It needs to assemble context from:

• the current user message
• attachments
• recent conversation history
• system and skill instructions
• user preferences
• long-term memory
• uploaded documents
• workspace files
• task history
• tool outputs
• browser or screen context
• safety rules

The hard part is not just collecting all of this.

The hard part is deciding what the model should actually see.

In Row-Bot, I’m treating context as a runtime pipeline rather than a giant prompt string.

The flow is roughly:

1. Gather candidate context from user input, memory, documents, tools, and conversation state
2. Rank and filter it by relevance, freshness, source priority, and conflicts
3. Deduplicate and summarise where needed
4. Fit it into the active model’s token budget
5. Preserve high-priority instructions and safety rules
6. Invoke the model
7. Write useful state back to memory, tasks, conversation history, or the local data store

One important part is trust boundaries.

Tool outputs are useful, but they are not trusted instructions.

Web pages, emails, documents, browser snapshots, shell output, and API responses can all contain prompt injection. So Row-Bot treats them as untrusted context. The model can summarise and reason over them, but it should not obey instructions inside them.

Another important distinction:

Memory is not context.

Memory is what the system stores long term. Context is what the model sees right now.

The context engine is what decides which memories, document chunks, tool results, and prior messages are relevant enough to include for the current task.

There is also a background refinement path, similar to a dream cycle, that extracts memories, summarises knowledge, updates the wiki vault, and generates insights using the same context assembly approach.

The goal is simple:

>

I think this is where a lot of personal AI agent work is heading. Bigger context windows help, but they do not remove the need for context engineering.

If anything, they make source priority, safety boundaries, and retrieval quality even more important.

Row-Bot is open source here:

https://github.com/siddsachar/row-bot

Curious how others are handling context in long-running agents. Are you mostly using RAG, conversation summarisation, graph memory, huge context windows, or some mix of all of them?

I’ve been working on Row-Bot, a local-first personal AI agent, and one of the areas I’m most interested in is self-awareness and controlled self-evolution.

Not “the AI secretly rewrites itself” type of self-evolution.

I mean something more practical:

An agent should be able to inspect its own state, understand what tools are enabled, diagnose failures, explain why something happened, manage settings safely, and improve repeated workflows with user approval.

The architecture I’m building has a central self-awareness layer that connects to:

• live system status
• capability registry
• enabled and disabled tools
• provider health
• diagnostics and logs
• task history
• skill system
• knowledge graph and wiki
• insights from the dream cycle
• settings control

The idea is that when the user asks something like:

>

or:

>

or:

>

the agent should not guess. It should inspect the live system and give an accurate answer.

For changes, everything routes through approval. Model switching, tool toggles, skill patches, task deletion, settings updates, and destructive actions all require confirmation.

The self-evolution part comes from a few controlled loops:

1. If a workflow is repeated, Row-Bot can propose turning it into a reusable skill.
2. If an existing skill is missing useful instructions, it can propose a patch.
3. If a troubleshooting pattern is found, it can save it as a self_knowledge memory.
4. If a task or provider keeps failing, it can surface that as an insight.
5. If a setting needs changing, it routes through a settings control path instead of silently changing itself.

The main principle is:

>

I think this is an important direction for personal AI agents. Tool use alone is not enough. Long-running assistants need observability, diagnostics, memory, permissions, and safe feedback loops.

Otherwise they become black boxes with access to too much.

Row-Bot is open source here:

https://github.com/siddsachar/row-bot

Curious how other people are thinking about self-improving agents. Do you prefer agents that can adapt over time, or do you think all behaviour should stay fixed unless manually configured?