A system for how AI agents present answers, actions and progress.
Xyne Spaces is a collaborative workspace where teams and AI agents work together across chats, tickets, and other tools. But in developers’ day-to-day workflows, bug reports, suggested fixes, and pull requests often got buried in long chat threads, making it difficult to track progress and review the agent’s work.
To solve this, we designed more structured, interactive responses that made plans easier to review, task progress easier to track, and code changes easier to understand.
While working on Xyne Spaces, I started using our internal AI agent in chat, Xyne Doctor, a lot. I was mostly using it to understand certain features better and also to work on UI bugs that I would run into while using the product.
And honestly, it was pretty powerful. It could trace an issue, do an RCA, come up with a fix, implement that fix, and even raise a PR by itself. That is a lot! But the more I used it, the more I started feeling this friction. The agent was useful, but the responses were hard to work with.
In longer-running threads, everything started to get buried. The plan, the changes it made, the sandbox link, the screenshots, the PR, all of it was there, but not in a way that was easy to consume. The chat started making the work harder instead of helping it move faster.
That was the starting point for this project. I was not trying to make the agent smarter; rather, I was trying to make what it said back actually usable.
At that point, everyone on the team, from developers and PMs to designers, was using agents for their own use cases in Spaces. I wanted to focus on the developer use case since developers were the main users of these agents.
Looking at the conversations in Spaces, I realised that developers mainly used two agents:
For context, Xyne Doctor helped investigate bugs, reason through them, suggest a fix, implement it, and raise a PR. In some cases, it could also give before and after screenshots or a recorded walkthrough of the RCA (this felt like I was living in some sci-fi movie tbh).
But I realised the problem was not that the agent was not doing enough. Everything came back as dense markdown inside chat, and once the thread got even a little lengthy, the response became difficult to grok and revisit.
So the problem was not at the intelligence layer, but at the communication layer.
Before designing, I wanted to understand the workflow of developers and PMs so that I could help them out.
During my discussions with engineers, I got to know that for Spaces, releases were happening very frequently, sometimes every day, and a few things kept coming up again:
Knowing all this made me excited to work on this problem statement since I had an opportunity to help developers on our team have a better developer experience and ship things faster.
I started looking for other applications that use agents to help get work done. I found Claude Tag, which works in Slack. Our team tested it out to see what Claude Tag could do and what kind of artifacts it produced. We got really good results from Claude Tag since it is powered by a frontier model.
This made me think about agent responses less as messages and more as a collection of things people need to review, act on, and come back to.
Initially, I started working on the planning widget. The current plan widget was non-interactive and got visually buried in the long threads, so it became difficult to come back to it later.
Now, the goal was to make the plan interactive so that the user had a checkpoint to review, approve, or adjust the proposed plan before letting the agent loose to write code.
The app has a minimal procedural sound layer with no @web-kits/audio, no SoundDefinition schema, and no React audio context.
5 To-dos Selected
While working on this, I also wanted to help with the SDLC process. A PR is one of the clearest signals of movement in this workflow for developers, so I wanted to surface that properly in chat for both developers as they raise these PRs and Product Managers to review and approve them.
Essentially, a PR has 4 stages:
Also, an important design decision here was that I did not want to recreate GitHub or Bitbucket inside Spaces. Those tools already solve things like diffs and code review comments very well. So instead of copying all of that, I focused on making the PR component useful in context.
So I thought of them less like attachments and more like structured outputs that needed to have their own place in the responses. This was also important for Product Managers, as they did not always need the full breakdown, but needed enough to understand what changed and whether it worked.
Problem Description. Issue 1 Automation steps (update-tags, update-form-fields, send-email-reply, send-csat-request, assign-ticket, assign-ticket-to-group, change-stage, update-ticket) were not creating any audit trail entries when executed by automation.
While using Xyne Doctor to fix UI issues, a problem I faced was that there was no feedback on whether the agent was working on something or not, as it often went quiet for a while and worked in the background.
So to fix this, I wanted to show not the full chain of thought, but enough feedback to the user to not feel like the system had gone cold or something had failed.
Something that was a bit more experimental was that the agent was aware of the conversation and the project context being discussed in chat/threads, so it could suggest next steps like syncing up a meeting with folks involved in the project.
The complex bit in this was figuring out how to surface enough metadata for people to accept the meeting suggestion: who is present for the meeting, what the agenda is, and, most importantly, how to coordinate between the free time slots of everyone involved, take in time suggestions, and then schedule a meeting.
This idea was more exploratory, but it came from the same place. If the agent is part of the workspace, it should help us accelerate the work.
Available slots
After implementing the initial composer changes, the feedback I got from users was that they also wanted to understand the chain of thought and the tool/MCP calls that were made.
While working on this problem statement, I changed my approach a bit. I still started with Figma to think through the basic direction, but I realised pretty quickly that static mockups were not enough, as these components would change state over time and also have other states depending on different interactions. I wanted the stakeholders to feel this so the vision could be communicated well and they could buy into it.
So I started building these individual pieces as HTML artifacts first to make it easier for me to iterate on, since this was a sandboxed environment. From my previous experience working with production code, whenever I asked Claude to change things, it would touch 10 different files since some things had dependencies in those files.
Here, in an HTML artifact, I could isolate one component, test all its states, work through the interaction details, and understand how it would actually show up in the chat surface before bringing it into the main codebase. It saved a lot of back and forth.
Once a component felt right there, it became much easier to move it into the real product!
I always enjoy working on interesting problem statements and helping out folks around me. This problem statement was close to me as it leans towards my archetype as a designer with engineering curiosity.
Earlier, I thought an agent made life a lot easier for engineers, but while working on this project, I realised it can be powerful and still feel frustrating, hard to trust, or difficult to act on.
That is why I started treating the response layer as the actual product and not as a wrapper on top of the intelligence.
While designing, I also had to think about how progress is shown, how trust is built, how handoff happens, how people keep moving, and what errors would look like.
On a more personal level, this project also helped me understand the SDLC more deeply. I got to know how developers think about bugs, fixes, PRs, testing, and release flow. While at it, I found a better process for myself to work with AI.