Ability to customize the Agents Window interactions

Ideas Feature Requests
1

Feature request for product/service

Chat

Describe the request

We would like to use Agents Window as a channel for end user to experiment with our platform and its features in a dedicated environment. We enabled that by adding local gitignored files on each end user’s workstation, but it’s a clunky job.

Would be great to have a json config, that we can distribute to end users based on their roles. The config would define what they can and cannot do in the Agents Window, and enable extra custom fields loadings such as user_email, user_role, etc. Maybe even custom forms to standardise requests.

This would help us to enable end users to follow their particular flow in a simple chat experience without looking at the code, while our agents framework runs their experiments in the background.

A good example would be client’s marketing team wanting to change content on our platform. they would make a request in Agents Window, which identifies them as marketing team, checks their restrictions, i.e content-only needs no approval, verifies changes and proceeds with SDLC.
Another example is the business owner who wants to experiment with features.

That would turn cursor’s Agents Window from coding assistant to platform customization assistant tool.

Operating System (if it applies)

Windows 10/11
MacOS
Linux

5

Hey @pedanticgeek

Thanks for the idea! This is probably a level of role-based customization we don’t anticipate bringing to the Agent Window, but I can think of a couple of other options that’d get you close.

You could build it out with the Agent SDK. That’d mean a small app on top of the SDK for each role, with whatever custom fields and forms you want (user_email, user_role, etc.), which then hands the request off to an agent to work through and raise a PR. Same simple chat experience for your users, but the role logic lives in your app instead of on every machine.

And even without building anything on the SDK, an Automation could handle just the approval side of PRs raised by your team. Since the request carries the requestor info, it can make an approval decision based on the risk and scope of the changes, e.g. content-only goes straight through, anything broader gets routed to a human.