It's mainly a full chat app like e.g. ChatGPT. However our platform also comes with a Outlook/Office add-in, where our UI is directly displayed besides the email/document you are actively working with. There we are mostly restricted by the surface that the add-in system provides us. To some level we can take current user interactions into account (e.g. what email are you currently viewing), which already helps a ton, but there are other restrictions that can get quite limiting.

So you have two main modes of operations: One-shot "I have this input; give me this output" which people usually do via the web-app, and more interactive editing to documents (usually larger ones) that happens directly in the applications the users are already working in.

And yeah, that's what ultimately gets the job done. We've seen competing solutions dive much deeper into building their own native editors, but they always lack the fidelity required by power-users, and are usually not as acepted by the broader workforce that are entrenched in their ways (our typical end-user is 50+ in a enterprise-like organization structure), so we try to meet the organisations where they are.

Thanks for your feedback.

The 'main' section is HTML, so it can be any type of workspace you want. Our agent can read/write (with permissions, of course) and can execute code locally (again, with permissions).

The HTML pages we generate are backed by a schema and state per 'workspace', so they persist, can be shared between team members, and aren't just ephemeral read-only artifacts.

Our agent can do work on your machine for you, it has an integrated web browser that allows it to not only search and retrieve info but also perform web-based tasks, and it can package everything up into a nice little contained UI for you so you're not jumping between multiple apps / documents / tabs. That UI is tied back to whatever document / page you were working in -- so for instance our app can have a form that updates a web page, or updates a document on disk and vice versa.

The plainness is deliberate, the design of the workspaces is up to you -- it's your UI not mine and the agent will design everything how you like it. And as far as the sidebar/text input combination goes I can assure you I have spent a lot of time imagining what this UX should look like and frankly this combo just makes sense.

Also a note on the text input / agent. When you move from text conversations to dynamic HTML interfaces you're faced with a question: how do you relate 'conversations' with the agent to workspaces? A one-to-one conversation to workspace mapping? Many-to-one, one-to-many? Should conversations be time-based, where I just start a new one and have to provide context again and can optionally link back to old conversations if I want? This question is actually quite difficult, but my belief was that ultimately you want just one single global conversation with the agent, and you want to let it handle its own memory internally. We basically just treat memory like a codebase and let the agent decide what to do. This means when you type in the text input you can refer to anything you like: any workspace, any conversation, any webpage you're currently browsing, any folder on disk -- the agent gets the right context and can retrieve relevant details as it needs. And it works!

So sure, I'm not a designer no matter how hard I try -- there will be far better UX out there than I've designed. But I think the fundamental mechanism in Radix is more sophisticated than most other tools, including Cowork etc (no shade at all to anyone, I'm a massive fan of Claude Code).