Devlog #7 — Multi-Agent Architecture & Custom Agent Builder

Zero-Assist just got a major upgrade.

What if instead of one AI assistant, you had an entire team of AI specialists working together?

That’s exactly what I’ve built.

Multiple Agent System

Zero-Assist now supports multiple specialized agents, each optimized for a specific role and workflow.

Master Agent

The brain of the operation.

• Orchestrates all agents
• Assigns tasks intelligently
• Monitors progress
• Routes requests to the best agent

Researcher Agent

Your personal information hunter.

• Searches the web
• Collects and analyzes data
• Returns structured insights
• Filters noise and focuses on relevant information

Coder Agent

Built for developers.

• Writes code
• Reviews code
• Fixes bugs
• Assists with architecture and implementation

Planner Agent

Turns chaos into clarity.

• Breaks down goals
• Creates actionable roadmaps
• Generates timelines
• Organizes complex projects

---

Custom Agent Builder

The most exciting feature in this update.

You can now create your own specialized AI agents with just a few clicks.

Customize:

• System Prompt
• Temperature
• Tags & Capabilities
• LLM Model
• Agent Role & Personality

Want an AI Startup Advisor?

Create one.

Want a Bug-Hunting Expert?

Create one.

Want a Cybersecurity Specialist?

Create one.

The possibilities are endless.

---

Why This Matters

Most AI applications rely on a single model trying to do everything.

Zero-Assist takes a different approach.

Instead of one assistant, you get an entire ecosystem of AI specialists that can collaborate, delegate tasks, and work together to solve problems more efficiently.

Each agent has:

• Its own configuration
• Its own expertise
• Its own behavior
• Its own model settings

This creates a more scalable and intelligent workflow compared to traditional AI assistants.

---

Vision

The long-term goal isn’t just to build another chatbot.

It’s to build an AI Operating System where users can create, orchestrate, and manage teams of intelligent agents that work together to accomplish complex tasks.

And this is only the beginning.

Screenshot attached below.

---

#The Final Devlog
Riced my phone though is not a stand alone os but many linux package works in termux too cause basically the android is based on linux :D so most of the package were working and the one which were not working i ditched them , also setup ed a some developer apps like lazyvim via nvim , rofi , vscode , some hardware acc tools too !! also adding the video as the demo

#The Final Devlog
Riced my phone though is not a stand alone os but many linux package works in termux too cause basically the android is based on linux :D so most of the package were working and the one which were not working i ditched them , also setup ed a some developer apps like lazyvim via nvim , rofi , vscode , some hardware acc tools too !! also adding the video as the demo

#Devlog 6 -Zero-Assist

Shipped a big update today. The app can now handle complex tasks much more reliably, and tools run in parallel instead of sequentially — so heavy workloads finish noticeably faster without the app choking midway.
The smarter behavior actually came from Trimming down the soul.md, longterm-memory.md, agents.md, and user.md files reduced token usage significantly, and the model started reasoning better almost immediately. I tested it across several complex tasks and the output quality genuinely caught me off guard — results I didn’t expected!!!

Voice has been a pain point for a while. Dug into the Piper latency issues, restructured the integration, and the pipeline is much smoother now. Still sounds robotic — that’s a problem I haven’t cracked yet — but the lag that made it frustrating to use is mostly gone.
Overall the app feels like a different version of itself. More capable, leaner, and faster. Dropping Demo vid of the test runs below so you can see what it’s actually doing now. here is demo video too :https://youtube.com/shorts/F8sLD21dcWo

#Devlog 6 -Zero-Assist

Shipped a big update today. The app can now handle complex tasks much more reliably, and tools run in parallel instead of sequentially — so heavy workloads finish noticeably faster without the app choking midway.
The smarter behavior actually came from Trimming down the soul.md, longterm-memory.md, agents.md, and user.md files reduced token usage significantly, and the model started reasoning better almost immediately. I tested it across several complex tasks and the output quality genuinely caught me off guard — results I didn’t expected!!!

Voice has been a pain point for a while. Dug into the Piper latency issues, restructured the integration, and the pipeline is much smoother now. Still sounds robotic — that’s a problem I haven’t cracked yet — but the lag that made it frustrating to use is mostly gone.
Overall the app feels like a different version of itself. More capable, leaner, and faster. Dropping Demo vid of the test runs below so you can see what it’s actually doing now. here is demo video too :https://youtube.com/shorts/F8sLD21dcWo

Devlog #4 — Termux Desktop

No new features today — just fixing stuff that was manual hardwork

Problem:

The setup used one big pkg install to install everything at once. Turns out if even one package fails (like websockify hitting a bad mirror errors again and again ), the whole command dies and nothing else .

What I Fixed

I Split everything into two scripts:

setup.sh — runs once, installs all packages one by one so a single failure doesn’t kill the rest, downloads noVNC, and sets up the home-screen widget
start-desktop.sh — unchanged, just launches the desktop like before

The widget thing is probably my favourite part of today. setup.sh now automatically creates the Termux:Widget shortcut, so after first-time setup you just tap a button on your home screen to start the desktop. No opening Termux, no typing. Actually plug and play now.

Also rewrote the README to match all of this.

What Didn’t Work Out

Had an idea to build a proper Android app that wraps everything — no terminal at all. But Android sandboxes apps from each other so an APK can’t actually run pkg install inside Termux. It would’ve been a lot of work for not much gain over the widget shortcut. Dropped it.

Next

Testing everything on a real device tomorrow. Fingers crossed setup.sh doesn’t explode.

Devlog #4 — Termux Desktop

No new features today — just fixing stuff that was manual hardwork

Problem:

The setup used one big pkg install to install everything at once. Turns out if even one package fails (like websockify hitting a bad mirror errors again and again ), the whole command dies and nothing else .

What I Fixed

I Split everything into two scripts:

setup.sh — runs once, installs all packages one by one so a single failure doesn’t kill the rest, downloads noVNC, and sets up the home-screen widget
start-desktop.sh — unchanged, just launches the desktop like before

The widget thing is probably my favourite part of today. setup.sh now automatically creates the Termux:Widget shortcut, so after first-time setup you just tap a button on your home screen to start the desktop. No opening Termux, no typing. Actually plug and play now.

Also rewrote the README to match all of this.

What Didn’t Work Out

Had an idea to build a proper Android app that wraps everything — no terminal at all. But Android sandboxes apps from each other so an APK can’t actually run pkg install inside Termux. It would’ve been a lot of work for not much gain over the widget shortcut. Dropped it.

Next

Testing everything on a real device tomorrow. Fingers crossed setup.sh doesn’t explode.

Termux :Desktop devlog#3 — the big script cleanup

tl;dr

had two separate startup scripts doing almost the same thing and it was bothering me
merged everything into one unified launcher with a proper menu (A / B / C)
termux:x11 is now option A and actually works cleanly alongside the vnc stuff
script auto-detects usb tethering vs wifi so you don’t have to think about it
xrdp falls back to novnc automatically if usb isn’t connected (so it doesn’t just die)
updated the readme to actually reflect what the project does now
github: Tanmay-1122/Termux-desktop

what i changed

the big merge (two scripts → one)

before this i had termux11start.sh for termux:x11 and start-desktop.sh for the vnc/xrdp stuff. they were basically doing the same cleanup and xfce setup steps just slightly differently. every time i wanted to fix something i had to do it twice which was annoying so i just merged them.

now there’s one script that shows a menu when you run it:

A) Termux:X11 — hardware-accelerated ⚡
B) noVNC — browser access (wifi) 🌐
C) xRDP — windows rdp via usb 🪟

pick your mode, it handles the rest.

network detection up front

script now checks for usb tethering (rndis0 / usb0) and wifi (wlan0) before showing the menu
both ips are shown at the top so you know what’s available before you even pick a mode
option C shows a warning in the menu itself if usb isn’t detected instead of letting you pick it and then failing

shared helper function

pulled the .xsession and .Xclients setup into one setup_xsession() function
termux:x11 mode doesn’t need this at all (it runs on :0 not :1) so it skips it entirely
vnc and xrdp both call it — no more copy-pasted code

termux:x11 mode (option A)

pulled the logic from termux11start.sh and cleaned it up a bit:

starts pulseaudio with tcp auth so audio actually works
launches termux-x11 :0 in background, waits 3 seconds
calls am start to bring the x11 app to the foreground automatically
sets PULSE_SERVER=127.0.0.1 and DISPLAY=:0 then launches xfce4

xrdp fallback

if you pick option C but usb isn’t connected, instead of crashing or doing nothing it prints a message and automatically falls back to novnc mode after 3 seconds. small thing but made it way less frustrating to use.

readme rewrite

the old readme only talked about termux:x11. rewrote it to cover all three modes with:

a comparison table so people can pick the right mode for their situation
separate install instructions for novnc and xrdp (tigervnc, websockify, xrdp packages)
a preview of what the launcher menu actually looks like
connection instructions for each mode (what url to open, what app to use, etc.)

Termux :Desktop devlog#3 — the big script cleanup

tl;dr

had two separate startup scripts doing almost the same thing and it was bothering me
merged everything into one unified launcher with a proper menu (A / B / C)
termux:x11 is now option A and actually works cleanly alongside the vnc stuff
script auto-detects usb tethering vs wifi so you don’t have to think about it
xrdp falls back to novnc automatically if usb isn’t connected (so it doesn’t just die)
updated the readme to actually reflect what the project does now
github: Tanmay-1122/Termux-desktop

what i changed

the big merge (two scripts → one)

before this i had termux11start.sh for termux:x11 and start-desktop.sh for the vnc/xrdp stuff. they were basically doing the same cleanup and xfce setup steps just slightly differently. every time i wanted to fix something i had to do it twice which was annoying so i just merged them.

now there’s one script that shows a menu when you run it:

A) Termux:X11 — hardware-accelerated ⚡
B) noVNC — browser access (wifi) 🌐
C) xRDP — windows rdp via usb 🪟

pick your mode, it handles the rest.

network detection up front

script now checks for usb tethering (rndis0 / usb0) and wifi (wlan0) before showing the menu
both ips are shown at the top so you know what’s available before you even pick a mode
option C shows a warning in the menu itself if usb isn’t detected instead of letting you pick it and then failing

shared helper function

pulled the .xsession and .Xclients setup into one setup_xsession() function
termux:x11 mode doesn’t need this at all (it runs on :0 not :1) so it skips it entirely
vnc and xrdp both call it — no more copy-pasted code

termux:x11 mode (option A)

pulled the logic from termux11start.sh and cleaned it up a bit:

starts pulseaudio with tcp auth so audio actually works
launches termux-x11 :0 in background, waits 3 seconds
calls am start to bring the x11 app to the foreground automatically
sets PULSE_SERVER=127.0.0.1 and DISPLAY=:0 then launches xfce4

xrdp fallback

if you pick option C but usb isn’t connected, instead of crashing or doing nothing it prints a message and automatically falls back to novnc mode after 3 seconds. small thing but made it way less frustrating to use.

readme rewrite

the old readme only talked about termux:x11. rewrote it to cover all three modes with:

a comparison table so people can pick the right mode for their situation
separate install instructions for novnc and xrdp (tigervnc, websockify, xrdp packages)
a preview of what the launcher menu actually looks like
connection instructions for each mode (what url to open, what app to use, etc.)

ZERO-ASSIST devlog 1
IM working on Zero-Assist voice assistant app on which im already working from March , the app has lots of features , i completely vibe coded the app but now im working on the finishing part of the app so today i improve the voice assist mode , the voice was really slow on cheaper Android phones. When you spoke to it, you’d wait 10+ seconds before hearing the voice response.

What I fixed today
1️⃣ Made It Stop Waiting So Long
Before: App waited up to 2.5-5 seconds to make sure the TTS Engine was ready
Now: Only waits 0.9-1.8 seconds
Result: Faster feedback !!
You can also check the app here (https://github.com/Tanmay-1122/Zero-Assist)

Devlog 5 – Channel Integration and Tool Access

Today I spent most of my time working on one of the biggest features of the project so far: Channel Integration.

The channels system already supports multiple platforms such as Telegram, WhatsApp, Slack, Discord, and several others. My goal was to connect these channels with the assistant so that it can interact with users across different platforms while still having access to the tools and capabilities available on the phone.

To achieve this, I worked on properly connecting the Rust bridge with the Kotlin application. Once the communication layer was working correctly, I was able to expose several powerful capabilities to the assistant, including:

• Access to phone storage and files
• Accessibility-based device control
• Web tools and online actions
• Composio integrations
• File management and manipulation
• Cross-platform channel communication
• Various assistant tools that were previously isolated from each other

This was a fairly complex task because multiple systems needed to communicate reliably. I also used AI assistance throughout the development process to help debug issues, validate approaches, and speed up implementation. In total, this work took roughly 12 hours.

At the moment, I have not pushed the code to the repository because the feature still requires extensive testing. Since it touches storage access, tool execution, and communication across multiple services, I want to ensure everything is stable before making it public. Once I complete the testing phase, I will push the implementation to the repository.

This feature significantly expands what the application can do. Instead of being just a chatbot, it is evolving into a full assistant platform capable of interacting with external services, managing files, controlling parts of the device, and communicating through multiple messaging platforms. The long-term vision is to create a system where users can build highly capable personal assistants that can perform real tasks rather than simply generate text.

There is still a lot more work ahead, but today’s progress was a major step toward that goal. Stay tuned—some very exciting features are currently in development.

Devlog 5 – Channel Integration and Tool Access

Today I spent most of my time working on one of the biggest features of the project so far: Channel Integration.

The channels system already supports multiple platforms such as Telegram, WhatsApp, Slack, Discord, and several others. My goal was to connect these channels with the assistant so that it can interact with users across different platforms while still having access to the tools and capabilities available on the phone.

To achieve this, I worked on properly connecting the Rust bridge with the Kotlin application. Once the communication layer was working correctly, I was able to expose several powerful capabilities to the assistant, including:

• Access to phone storage and files
• Accessibility-based device control
• Web tools and online actions
• Composio integrations
• File management and manipulation
• Cross-platform channel communication
• Various assistant tools that were previously isolated from each other

This was a fairly complex task because multiple systems needed to communicate reliably. I also used AI assistance throughout the development process to help debug issues, validate approaches, and speed up implementation. In total, this work took roughly 12 hours.

At the moment, I have not pushed the code to the repository because the feature still requires extensive testing. Since it touches storage access, tool execution, and communication across multiple services, I want to ensure everything is stable before making it public. Once I complete the testing phase, I will push the implementation to the repository.

This feature significantly expands what the application can do. Instead of being just a chatbot, it is evolving into a full assistant platform capable of interacting with external services, managing files, controlling parts of the device, and communicating through multiple messaging platforms. The long-term vision is to create a system where users can build highly capable personal assistants that can perform real tasks rather than simply generate text.

There is still a lot more work ahead, but today’s progress was a major step toward that goal. Stay tuned—some very exciting features are currently in development.

Devlog 2 – Added Rofi Application Launcher

Today I worked on improving the usability of my Termux Desktop project by integrating Rofi as the main application launcher.

Before this change, launching applications was less convenient and required navigating through menus or using terminal commands. To solve this, I added a custom Rofi setup that allows applications to be launched quickly from a clean search interface. I also created a keyboard shortcut so that pressing Super + Space instantly opens Rofi, making the desktop experience feel much more natural and efficient.

While implementing Rofi, I spent time customizing its appearance and layout so that it better matches the overall desktop environment. The launcher now looks cleaner and is easier to use compared to the default configuration.

One challenge during this session was finding the right balance between functionality and appearance. I experimented with different configurations before settling on a design that feels responsive and visually appealing.

I am currently working on the next phase of the project. My goal is to implement noVNC and XRDP support. With noVNC, users will be able to access the Termux desktop through a web browser on any device connected to the same network. This means the desktop will not be limited to Termux:X11 and can be accessed from PCs, tablets, or other screens using only a browser.

I also plan to add XRDP support, which will allow Windows users to connect directly to the Termux desktop using Remote Desktop. This should provide a smoother and more native experience while making the setup significantly more portable.

In the future, I will also publish my desktop configuration files (dotfiles) on GitHub so that others can easily recreate the same setup.

Overall, today’s work focused on improving accessibility and user experience, bringing the project one step closer to feeling like a complete desktop operating system rather than a Linux environment running on a phone.

Rofi screenshots are attached below.

Devlog 2 – Added Rofi Application Launcher

Today I worked on improving the usability of my Termux Desktop project by integrating Rofi as the main application launcher.

Before this change, launching applications was less convenient and required navigating through menus or using terminal commands. To solve this, I added a custom Rofi setup that allows applications to be launched quickly from a clean search interface. I also created a keyboard shortcut so that pressing Super + Space instantly opens Rofi, making the desktop experience feel much more natural and efficient.

While implementing Rofi, I spent time customizing its appearance and layout so that it better matches the overall desktop environment. The launcher now looks cleaner and is easier to use compared to the default configuration.

One challenge during this session was finding the right balance between functionality and appearance. I experimented with different configurations before settling on a design that feels responsive and visually appealing.

I am currently working on the next phase of the project. My goal is to implement noVNC and XRDP support. With noVNC, users will be able to access the Termux desktop through a web browser on any device connected to the same network. This means the desktop will not be limited to Termux:X11 and can be accessed from PCs, tablets, or other screens using only a browser.

I also plan to add XRDP support, which will allow Windows users to connect directly to the Termux desktop using Remote Desktop. This should provide a smoother and more native experience while making the setup significantly more portable.

In the future, I will also publish my desktop configuration files (dotfiles) on GitHub so that others can easily recreate the same setup.

Overall, today’s work focused on improving accessibility and user experience, bringing the project one step closer to feeling like a complete desktop operating system rather than a Linux environment running on a phone.

Rofi screenshots are attached below.

Devlog:1 Termux Desktop
Hello everyone , this is my new project (Termux Desktop) which can turn any normal android device into a full fledged linux desktop environment within few clicks , i already worked for something similar to this as my personal protect but it required lots of manual work and debugging but now in this protect i will try to automate everything and within the few clicks you will be able to turn your phone to a pc , i have lots of idea in my mind will go step by step

So what i did today !!: so today i worked on setting up a very basic linux gui environment using the Termux and the Termux x11 where i was able to get the display output of the phones native Termux on the Termux x11 as shown in the image

i also made a automated script to start the display x11 server automatically when run the command in the Termux’s terminal , it will automatically open the Termux x11 with the linux !

Devlog:1 Termux Desktop
Hello everyone , this is my new project (Termux Desktop) which can turn any normal android device into a full fledged linux desktop environment within few clicks , i already worked for something similar to this as my personal protect but it required lots of manual work and debugging but now in this protect i will try to automate everything and within the few clicks you will be able to turn your phone to a pc , i have lots of idea in my mind will go step by step

So what i did today !!: so today i worked on setting up a very basic linux gui environment using the Termux and the Termux x11 where i was able to get the display output of the phones native Termux on the Termux x11 as shown in the image

i also made a automated script to start the display x11 server automatically when run the command in the Termux’s terminal , it will automatically open the Termux x11 with the linux !

Zero-Assist Devlog #4 — The Phone Is Now a Personal Chat Server
so Devlog 4 is here.

The main thing i fixed this time is the channels section of the app. channels are basically how Zero-Assist can gets input or give output to other app — like Telegram, WhatsApp, and other messaging apps. once you connect them, the app starts listening.
but whats different now that channels are working, the phone isn’t just an AI assistant anymore. it’s your personal home server that you can message like a real in-person.
what this actually means in practice:
say you’re away and you message your own Telegram bot: “water the plants” — Zero-Assist picks that up, figures out what you mean, and either goes with an MQTT signal to your smart home setup or directly talks to your microcontroller over USB or BLE , whichever is available. no extra apps, no cloud, just your phone doing the work.
same idea works for your homelab. you can message “ping my website” and the app will run the actual shell command on your phone and report back. this does need a one-time manual connection to set up, but after that it just works.
basically the phone becomes a chat-controlled home automation that you own fully here is no cloud included except the llm , which you can also use the local llm .
what i’m planning to add next:
i’m planning a live dashboard screen for this — not raw logs, but a simplified readable feed. something like:
“message received via Telegram → running plant watering command → sent MQTT signal ✓”
the idea is it’s useful for people who like seeing what’s happening here, but written in plain language instead of technical stuff for the normal users .
the hard part this time was :
most of the time on this devlog went into connecting the Rust backend (which handles all the channel logic) to the Kotlin front-end of the app , so getting them to work together cleanly took a lot of debugging and was honestly the most frustrating part of this whole update. got it working though.
more soon.

devlog -3

added a new shared folder option int the app so that the app can share the storage from phone , it can open files edit files , manipulate the files and do lots of stuff with it , added the screenshot below

Devlog #2 is here!!

so after the piper TTS update in devlog #1, I’ve been working on something
way bigger — I added Composio integration to Zero-Assist

for those who don’t know what composio is — it’s basically a platform that
connects AI agents to over 1,000 apps like Gmail, Slack, GitHub, Notion,
Salesforce, Google Drive and a lot more. think of it as the bridge between
your AI and the rest of the internet.

so now Zero-Assist can actually do things for you like —

→ send and read messages (if you give it the right permissions)
→ make notes in Notion automatically
→ send mails on your behalf
→ store your files to Google Drive
→ and a lot more depending on which apps you connect

the best part is this feature was already there inside ZeroClaw (which is
what Zero-Assist is built on), so it wasn’t built from scratch — it was
more about bringing it properly into the Android app and making it actually
usable.

check out the video (https://drive.google.com/file/d/1ZO56Ekrq7fu205Epqx8fH-Vkt_E5xc16/view?usp=sharing) for a small demo of how it works