I completely agree with you that the chat interface is very undercooked and there's a big untapped space for agent-first interfaces, perhaps even replacing traditional desktop metaphors. You're spot on with your premise.
With that said, from the material you show in your homepage, it still seems like you're doing something very similar to OpenAI and Anthropic's first party apps?
I think it would help your pitch if you could show some task or workflow where your interface truly makes a difference; loading files and asking questions about them is a staple of most harnesses.
I think a better example is how Marble makes tools visible and easy to select for each task instead of requiring you to remember what exists or describing everything through the prompt.
Marble keeps the tools you use most close at hand and will surface other useful ones for the job. Combined with a birds eye view of multiple tasks running, it makes agent work easier to set up and manage. The goal is to minimize cognitive overhead in day to day tasks (both in specifying what you want, and managing after you ran something)
Best interface in my opinion is a git tracked folder, files as state, agents coming in and doing work. It's not just a chat interface because in chat mode everything flows like water under the bridge. It is files as agents, where you get the agent to write a task in a file, and then it updates the file like a blackboard as it performs work. Same task file can be seen by worker agent, multiple judge agents (for plan and implementation), documentation agents and reflexion agents (improve workflow). I would also track every user message in a chat_log.md for reflexion agents (what is wrong with the workflow) and intent review (is the agent still following user intent?).
Whether or not it's a transitional phase, it seems reasonable to want and to build better tools for where we are now rather than where we may be in some unspecified future, wouldn't you say?
Agents frequently go off on tangents, make wrong decisions, require feedback etc. Agents have never moved away from being a junior that knows everything about programming but has no idea how to properly apply it.
We think that humans will remain in charge for quite some time. Even a superintelligence won't know what we want until we tell it. The process of communicating intent/desires etc to an AI agent is a nontrivial interface problem (which Marble is trying to get at).
A quick FYI: at marbles.com/learn, starting from „Turn Messy Notes into Today’s Task List“ the demo videos don’t work for me. I tried Safari and Chrome.
This is definitely an iterative improvement on what we have today. However, I think from a fundamental approach, you've just highlighted the pain of working with AI that I hadn't quite been able to verbalise until seeing this.
Go and have a look at the history of Microsoft OLE and OpenDoc and you'll see some of these ideas have been around for a while. When these ideas were first being shared in the industry (and yes, I am that old), here's the story that was being told:
In the future, you wouldn't buy "a word processor" or "an image editor", you'd buy components that could do specific tasks, and you'd bring them to your document/work as and when you needed. I'd have DTP components for layout, word processing components for spell checking, image components for resizing and colour balancing, and I'd be heads down in my fancy newsletter or report, and I'd be bringing functionality to the work I needed to do, without having to context switch and import/export things by hand.
The demo you've shown on the homepage is almost the opposite of this: I'm not bringing things into my work (fanning in), I'm starting agents to go and do lots of different bits of work (fanning out), that eventually I'm going to need to think about how to structure and fan in again.
I think coding interfaces kind of force us into a fan-in: here's my code base, now I want to improve test coverage, now I want to refactor, now I want to add this SDK, now I want to change this logic to use the SDK based on configuration params, now I want to improve my integration tests, and so on. I'm flowing through my work in a single asset (the code base), and able to bring agents and other tools to it.
Now, I'd like that, but for everything else. The UI I'd like allows me to build around the assets I am building.
Planning a trip? OK, I need to bring various agents along to help me plan an itinerary (in my calendar), based on location, budget, and preferences. It's not good enough to list the top 10 must-see places in Venice, I need them to fit into my calendar including travel time, and my budget - I want agents to help me plan that out. Ideally I want agents to help me and my partner both contribute to that based on our wants.
Need to do a report for the big boss? OK, I need to start with an empty report doc, and bring various sources of data, and take it through transformations to build the narrative/deck I need to write. Here's some excel data, here's an agent that can do some competitive analysis, here's another that is pulling quotes from real customers on social media, and so on...
Want to learn a new skill? We're going to need to have a framework for assessing where I am in terms of that skill (the "single asset" we're working on is "what I know"), and then agents to figure out the best way for me to fill gaps and reinforce what I already know.
Your demo is nicer than a chat box, but I think you need to think about the job that needs to be done, and how to bring agents to that job (perhaps even suggest those jobs - that could be another agent), not build a UI to just allow me to fire off dozens of agents that then have output sat in multiple windows across my screen.
I don't think we should homage GUI for AI agent workflows. The terminal and Mac GUI are 100% deterministic when you click an icon, but I'm not sure if visualizing agent workflows is the right call.
The problem is that AI workflows are inherently different for each person.
The current approach feels like it's forcing a CLI-based model on users. I also don't think chat is a suitable fundamental unit for task delegation.
I've worked on writing a compiler using both hand-written code and AI. Once the project exceeds a certain size, the chat itself becomes a bottleneck. In those cases, I needed proof and gates like Rocq. So in essence, AI coding requires clear negative gates that should be rejected when approaching the goal.
I think something like Figma's canvas model might become the new interface.
Because no matter how meta you make it, agent workflows are ultimately optimized for the individual. My settings often don't match someone else's.
Computers also have this problem, but in that case, you can enforce defaults. With AI agents, it's different.
That's why I think we need a canvas—something like a workspace next to the user space where agent workflows can be dynamically adjusted.
I focus most of my coding effort on building gates that AI-generated code must pass through when it's being produced. That approach has allowed me to handle much larger volumes of code.
The future agent GUI will be about supervising multiple asynchronous tasks.
In a way, this might end up resembling object-oriented programming—just with task graphs instead of object graphs.
Once AI starts generating code, it flows out like water through a burst dam. It's impossible for any human to fully understand it all. At first, I tried to understand every line, but that actually turned out to be less efficient than just writing the code myself. There's a clear fundamental mismatch between the way AI thinks about code and the way I do.
This mismatch seems like an unsolvable impedance mismatch problem—similar to the one between ORM and SQL. So once you decide to use AI agent code, you have no choice but to shift your focus from reviewing the code itself to trusting the gates you've built around it.
The key question is how tightly you can build those gates. And I don't think chat-based interfaces are capable of providing that level of control.
Totally agreed that chat interfaces won’t be sufficient to enforce complicated gates. Our interface does have the concept of a workspace, where you can see all the cards at-a-glance within the workspace. But graphs, or otherwise finding a way to have the tasks interact with each other, could be an interesting direction.
I think being able to view it as a graph would make things much faster. Because choosing to use AI means you're taking on work that exceeds your own cognitive limits.
For small tasks, you don't need AI. You can produce high-quality code just fine on your own. I can maintain very high quality for codebases up to about 40,000 lines. But using AI means you're trying to handle complexity at the scale of 100,000, 200,000, or even 300,000 lines, complexity that an individual can't fully digest. That requires an additional interface, and I believe that interface should be graph-based.
I agree with your view. I like this product quite a bit, but for controlling AI, I think it's still at the prototype stage
I completely agree with you that the chat interface is very undercooked and there's a big untapped space for agent-first interfaces, perhaps even replacing traditional desktop metaphors. You're spot on with your premise.
With that said, from the material you show in your homepage, it still seems like you're doing something very similar to OpenAI and Anthropic's first party apps? I think it would help your pitch if you could show some task or workflow where your interface truly makes a difference; loading files and asking questions about them is a staple of most harnesses.
I think a better example is how Marble makes tools visible and easy to select for each task instead of requiring you to remember what exists or describing everything through the prompt.
Marble keeps the tools you use most close at hand and will surface other useful ones for the job. Combined with a birds eye view of multiple tasks running, it makes agent work easier to set up and manage. The goal is to minimize cognitive overhead in day to day tasks (both in specifying what you want, and managing after you ran something)
Best interface in my opinion is a git tracked folder, files as state, agents coming in and doing work. It's not just a chat interface because in chat mode everything flows like water under the bridge. It is files as agents, where you get the agent to write a task in a file, and then it updates the file like a blackboard as it performs work. Same task file can be seen by worker agent, multiple judge agents (for plan and implementation), documentation agents and reflexion agents (improve workflow). I would also track every user message in a chat_log.md for reflexion agents (what is wrong with the workflow) and intent review (is the agent still following user intent?).
Why are you assuming that the human is in charge? Needing a human to drive the AI is probably a transitional phase.
Whether or not it's a transitional phase, it seems reasonable to want and to build better tools for where we are now rather than where we may be in some unspecified future, wouldn't you say?
Agents frequently go off on tangents, make wrong decisions, require feedback etc. Agents have never moved away from being a junior that knows everything about programming but has no idea how to properly apply it.
We think that humans will remain in charge for quite some time. Even a superintelligence won't know what we want until we tell it. The process of communicating intent/desires etc to an AI agent is a nontrivial interface problem (which Marble is trying to get at).
These Todo items on the side in the video seem to be useful.
I'm not so sure about that tool toolbar. It might as well just be a tool selector dropdown in a typical chat window.
A quick FYI: at marbles.com/learn, starting from „Turn Messy Notes into Today’s Task List“ the demo videos don’t work for me. I tried Safari and Chrome.
This is definitely an iterative improvement on what we have today. However, I think from a fundamental approach, you've just highlighted the pain of working with AI that I hadn't quite been able to verbalise until seeing this.
Go and have a look at the history of Microsoft OLE and OpenDoc and you'll see some of these ideas have been around for a while. When these ideas were first being shared in the industry (and yes, I am that old), here's the story that was being told:
In the future, you wouldn't buy "a word processor" or "an image editor", you'd buy components that could do specific tasks, and you'd bring them to your document/work as and when you needed. I'd have DTP components for layout, word processing components for spell checking, image components for resizing and colour balancing, and I'd be heads down in my fancy newsletter or report, and I'd be bringing functionality to the work I needed to do, without having to context switch and import/export things by hand.
The demo you've shown on the homepage is almost the opposite of this: I'm not bringing things into my work (fanning in), I'm starting agents to go and do lots of different bits of work (fanning out), that eventually I'm going to need to think about how to structure and fan in again.
I think coding interfaces kind of force us into a fan-in: here's my code base, now I want to improve test coverage, now I want to refactor, now I want to add this SDK, now I want to change this logic to use the SDK based on configuration params, now I want to improve my integration tests, and so on. I'm flowing through my work in a single asset (the code base), and able to bring agents and other tools to it.
Now, I'd like that, but for everything else. The UI I'd like allows me to build around the assets I am building.
Planning a trip? OK, I need to bring various agents along to help me plan an itinerary (in my calendar), based on location, budget, and preferences. It's not good enough to list the top 10 must-see places in Venice, I need them to fit into my calendar including travel time, and my budget - I want agents to help me plan that out. Ideally I want agents to help me and my partner both contribute to that based on our wants.
Need to do a report for the big boss? OK, I need to start with an empty report doc, and bring various sources of data, and take it through transformations to build the narrative/deck I need to write. Here's some excel data, here's an agent that can do some competitive analysis, here's another that is pulling quotes from real customers on social media, and so on...
Want to learn a new skill? We're going to need to have a framework for assessing where I am in terms of that skill (the "single asset" we're working on is "what I know"), and then agents to figure out the best way for me to fill gaps and reinforce what I already know.
Your demo is nicer than a chat box, but I think you need to think about the job that needs to be done, and how to bring agents to that job (perhaps even suggest those jobs - that could be another agent), not build a UI to just allow me to fire off dozens of agents that then have output sat in multiple windows across my screen.
I don't think we should homage GUI for AI agent workflows. The terminal and Mac GUI are 100% deterministic when you click an icon, but I'm not sure if visualizing agent workflows is the right call.
The problem is that AI workflows are inherently different for each person.
The current approach feels like it's forcing a CLI-based model on users. I also don't think chat is a suitable fundamental unit for task delegation.
I've worked on writing a compiler using both hand-written code and AI. Once the project exceeds a certain size, the chat itself becomes a bottleneck. In those cases, I needed proof and gates like Rocq. So in essence, AI coding requires clear negative gates that should be rejected when approaching the goal.
I think something like Figma's canvas model might become the new interface.
Because no matter how meta you make it, agent workflows are ultimately optimized for the individual. My settings often don't match someone else's.
Computers also have this problem, but in that case, you can enforce defaults. With AI agents, it's different.
That's why I think we need a canvas—something like a workspace next to the user space where agent workflows can be dynamically adjusted.
I focus most of my coding effort on building gates that AI-generated code must pass through when it's being produced. That approach has allowed me to handle much larger volumes of code.
The future agent GUI will be about supervising multiple asynchronous tasks.
In a way, this might end up resembling object-oriented programming—just with task graphs instead of object graphs.
Once AI starts generating code, it flows out like water through a burst dam. It's impossible for any human to fully understand it all. At first, I tried to understand every line, but that actually turned out to be less efficient than just writing the code myself. There's a clear fundamental mismatch between the way AI thinks about code and the way I do.
This mismatch seems like an unsolvable impedance mismatch problem—similar to the one between ORM and SQL. So once you decide to use AI agent code, you have no choice but to shift your focus from reviewing the code itself to trusting the gates you've built around it.
The key question is how tightly you can build those gates. And I don't think chat-based interfaces are capable of providing that level of control.
Totally agreed that chat interfaces won’t be sufficient to enforce complicated gates. Our interface does have the concept of a workspace, where you can see all the cards at-a-glance within the workspace. But graphs, or otherwise finding a way to have the tasks interact with each other, could be an interesting direction.
I think being able to view it as a graph would make things much faster. Because choosing to use AI means you're taking on work that exceeds your own cognitive limits.
For small tasks, you don't need AI. You can produce high-quality code just fine on your own. I can maintain very high quality for codebases up to about 40,000 lines. But using AI means you're trying to handle complexity at the scale of 100,000, 200,000, or even 300,000 lines, complexity that an individual can't fully digest. That requires an additional interface, and I believe that interface should be graph-based.
I agree with your view. I like this product quite a bit, but for controlling AI, I think it's still at the prototype stage