I’m building RalOS, an AI workspace where people and their agents can run a business together. Each person has an assistant. They can talk privately, bring it into a shared room, and work from the same conversations, company knowledge and records as the rest of the team.
The business I have in mind is a UAE office with salespeople, marketing, delivery, accounts and someone holding the whole thing together. A quote goes out. A customer asks for a change on WhatsApp. That changes what delivery has to do and what accounts can bill. All of those people need the same change, in the part of the business they work on.
RalOS is the product I’m building through Ralveto to connect that work. The beta already has people and local Codex or Claude Code agents talking in shared rooms. The larger product brings together the workflows, knowledge and follow-through described here.
I started with the way I work
My own setup is HarsOS. I use different AI tools for research, building, writing and the work around Ralveto. I’ve spent a lot of time teaching them how I think, what I’m working on, what I liked and what went wrong.
One thing kept coming up: I wanted the agents to manage the work with me. If an agent found something that made an old idea possible, I wanted it to make that connection and prepare the next step. If I corrected it, I wanted the next attempt to reflect the correction. Switching tools should carry that knowledge forward.
A company has its own version of this problem: people, customers, documents, promises and ways of doing things. An assistant becomes useful when it can work with those details, and a team benefits when that understanding survives beyond one person’s chat.
I’m starting with UAE small and medium businesses. I want the same design to make sense for a solo founder, a company with departments and, eventually, a group with brands and branches. A new intern joining sales should start with the right knowledge and access, without someone rebuilding their assistant from scratch.
One assistant per person, working with the team
Each person should have one obvious place to ask for help. A salesperson can ask for a quotation, a delivery manager can ask which projects need attention, and a founder can ask what needs a decision today.
Behind that assistant, different skills and specialists can handle the work. The sales methods differ from the accounts methods. People should be able to use them without learning how to manage a collection of bots.
Shared rooms are where collaboration happens. A person can mention an agent beside the discussion it needs to understand. Another person can bring their own agent into the same conversation. The work stays with the room, its thread and its files, so the next person can pick it up. A draft should appear ready to edit and approve, with the resulting message or changed record linked back to the job.
The longer-term agent setup includes bringing an existing agent, using a supported model subscription, or having a hosted agent that keeps working when the laptop closes. For jobs that need a browser or computer, I want people to see the agent’s screen, take over, and hand it back.
Access follows the person and the job. Sales needs customer and deal context. Accounts needs invoices and payments. A founder may need a view across both. Private HR information belongs with the people responsible for it. That has to remain understandable as the company grows.
Connect, Mirror, or Built in
A company should be able to arrive with software it already likes. Another might have everything in spreadsheets. Some will want a mix. I’ve kept three ways of working in the design.
Connect means keeping the existing tool and letting an agent work with it. If customer deals live in a CRM, the agent should look there for the current deal and act there when asked.
Mirror means bringing those records into a RalOS view. A team could see its deals beside the relevant conversations and tasks, while its existing CRM remains the place the record is maintained. Changes go through that source, and the view needs to show when it last checked it. Two people changing a deal at once should see the disagreement and resolve it.
Built in means using a tool inside RalOS, such as a project tracker or a simple CRM. A business starting fresh can use it directly. A company with a good accounts system can keep that and use RalOS for something else.
These choices can differ by job. A company might connect its email, mirror its pipeline and manage a new project inside RalOS. Odoo, Zoho or another business system can remain part of its setup. The useful question is where each record should live and how people need to work with it.
Start with the business’s knowledge
Onboarding should give the assistant a useful starting point. Tell it about the business by voice or chat, connect the relevant tools, bring existing documents and import useful history from other AI conversations. Then review what it understood: the people, customers, working language and recurring jobs.
I also want an employee to show how a job is done on screen while the agent asks questions. Someone who prepares the same document every week often knows exceptions they have never written down. Those details are part of the process worth capturing.
The knowledge base should preserve several views of what happened. Keep the raw source. Create a dated log of decisions and commitments, with citations back to it. Produce a readable synthesis for someone who needs the answer. Let them open the history to understand why it changed.
Suppose a team agrees to a different delivery date on a call. The source should show the actual agreement. The log should show when it changed and who agreed. The project should show the current date. An old summary should remain traceable without supplying the old date as today’s answer.
Search has to find an exact customer reference and a question phrased differently from the original conversation. It also has to distinguish a person’s decision from an agent’s suggestion. If notes disagree, the source, date and authority of each statement matter.
Live information stays connected to its source. An invoice balance belongs in the accounts system. The knowledge base can explain the payment terms and point to the invoice; the current balance should be checked where payments are recorded.
Memory needs upkeep too. Salience means giving more attention to what matters now: an active project or approaching renewal. Synthesis brings scattered details together. Old facts need review, replacement or archival. A person should be able to correct or remove something and understand what that changes.
Step Back, Interconnect, and Ripple
These are central to how I want an agent to work. The terms describe different parts of following something through.
Step Back means checking the purpose and what changed. If a customer moves a launch date, the useful question is what that does to the work around the launch.
Interconnect means finding the related commitments. The date may affect a delivery task, a campaign, a supplier booking, a promised update and an invoice. Some connections may sit in older conversations or work that was waiting for this decision.
Ripple means carrying the confirmed change to the relevant places. Update the authorised records, prepare the messages, and bring in the people whose work changed. The next person should open the project and find the current plan.
Then comes the next useful move. If the new date frees a team member, prepare the reassignment. If a customer sends the information holding up a quote, prepare the quote. If a meeting ends with a promise, connect it to a task and follow up when the promised date approaches.
The agent also needs judgment about when to speak. It may answer immediately, investigate first, prepare work in the background or stay quiet. A reminder should stop when the job is finished. A morning brief should bring forward what needs the person today, including work carried over and decisions waiting on them. The Today view should make it easy to see what needs you, what is in progress and what finished.
This is the behaviour I keep asking for in my own system: understand what a new event makes possible and do the useful preparation before bringing it back to me.
Give people methods they can use immediately
Prepared workflows and templates are a large part of RalOS. I want an agent to arrive with a useful way of doing the job, then adapt it to the company, person and situation. Current information can be researched when the task needs it.
For sales, that means preparing quotes and proposals from the company’s examples, keeping the next step attached to a deal, and drafting follow-ups when a customer goes quiet. When work is won, delivery needs the agreed scope and accounts needs the commercial details.
For projects and delivery, it means turning meeting decisions into assigned work, preparing client updates from what happened, chasing sign-offs, and keeping the handover together. The work history can also help someone account for their time without reconstructing the day from memory.
Support needs the customer’s request, the right account, a priority and the date somebody promised a reply. A solved problem can become a reviewed how-to for the next person. Accounts needs payment follow-ups, invoice drafts, statements and renewal reminders connected to the work being billed.
Marketing needs campaign briefs, calendars, posts, decks and creative work. HR needs leave and expense requests, letters, certificates and onboarding checklists. A founder needs a view across those jobs, with decisions brought forward. A multi-site business needs store audits, incidents, daily closes and follow-through across locations.
The industry changes the starting knowledge and documents. A shipping company needs freight quotations and shipment checklists. An accounting firm needs document requests and client deadlines. A software implementation team needs rollout plans, handovers and sign-offs. Travel, trading, property and e-commerce businesses have their own recurring work.
A template should capture how the company does the job: required information, accepted examples, the document’s shape and who reviews it. A routine adds when it runs. An automation connects the trigger to the work and its result. Together, these give people a starting process without requiring them to become good prompt writers first. Each automation should have someone responsible for its results, a history people can inspect and a way to pause it.
Add tools when the work calls for them
Just-in-time modularity means the workspace grows around the business. Start with what helps now. Add a department package, board, dashboard or document tool when there is a job for it.
If the team needs a tracker that does not exist yet, I want them to ask for it in chat. The agent should be able to build the view around the records and actions the job needs. That might be a renewal tracker, store-opening checklist or client approval page.
Useful outputs belong beside the conversation: a table, chart, document, project card or draft message people can open and work with. A client portal should show the client their files, approvals and progress while staff work from the same underlying record. The agency view can bring several client projects together. White-label versions are part of the longer-term design, so a company or agency can put its own brand on the experience.
That leaves room for a small company to stay small. A branch structure, extra department or more detailed view should appear when it helps someone do their work.
UAE first includes WhatsApp and voice
WhatsApp is part of the work I’m designing for: customer questions, quotes, follow-ups, staff requests and voice notes. Connecting a person’s agent to their WhatsApp should let them reach the assistant where they already talk and bring relevant work back to the shared workspace.
English and Gulf Arabic matter too. The agent should adapt to how the person speaks, explain things clearly and prepare a message in the language and tone the recipient needs. Voice should work for instructions, onboarding and talking through a task.
The same approach extends to Telegram, Teams, Slack and a phone app, alongside the web workspace and Windows and Mac desktop plans. People should be able to reach the work through a place that fits their day. I also want a personal space for each person, with their own context and tools, where they choose what to share with the business.
Local document practices, working hours, quiet hours and routines matter alongside language. Longer-term deployment choices include private hosting, UAE data options and the administration larger organisations need. UAE is the starting market; the product is designed to be adaptable beyond it.
Keep the company’s knowledge as models change
I want the business to keep what it has taught its agents. Its working knowledge includes far more than conversation text: skills, accepted examples, templates, instructions, corrections, sources and the history behind decisions.
That is what model independence means in the RalOS design. ChatGPT, Claude and other model tools can be part of the setup. The company should be able to change the model doing a job while retaining the business context and way of working around it.
I’m designing this to work in reverse, too. If you prefer Grok Bot, Claude or ChatGPT, the plan is to connect RalOS as a plugin or connector inside that app. You could ask your familiar assistant about a RalOS project or have it work on a task there, using the access you’ve given it. The company’s records stay connected whichever app you start from.
For developers, that means exposing the same work through an API, an MCP server and a command-line tool. Those are different ways for software to ask for the company’s records and actions.
No vendor lock-in has to include a usable way out: company knowledge, agents, skills, files and history in portable forms, with backups that can be restored. Keeping a useful setup should be the customer’s choice as the technology changes.
Control over data also needs choices about access, storage, model processing, retention and training. A private deployment and a provider’s zero-data-retention option belong in those deployment decisions. The company should be able to understand its setup and choose the one its work requires.
Let experience make the next job better
The advantage I want RalOS to build is accumulated understanding of how work gets done. A correction should improve the next draft. An accepted proposal should become a useful example. A failed automation should leave a lesson and a check that catches the same failure next time.
That is where HarsBench, my work on evaluating agents, connects to the product. I want the company to see whether assistance is getting more useful: accepted results, missed commitments, corrections, and time saved on a particular job. When a number says time was saved, people should be able to open it and see the work behind it.
Prepared methods can improve across repeated jobs while each company keeps its private information. Combined with UAE language and working habits, connected follow-through and freedom to change models, that is the advantage I’m working toward.
I’m building and using these ideas across HarsOS and Ralveto, and writing about the decisions here on byHARS. RalOS is where I’m bringing them into a product a business can sign up for, connect to its own work and shape around its team.