Transcript
We can, of course, use agents to help us automate this, but how do we manage control with agency? How do we find that right balance? To answer this exact pain point, we shipped issue intent. Let me show you how it works. In the Issues tab, we can use the Has Suggestions filter in order to view issues that have pending issue intent suggestions. I'll open this issue up here, and we can see for the suggestions, we have a confidence level and a reasoning. And we can also accept or decline each suggestion individually, or we can accept all up here. In our repository settings, under Planning, the current automation level is set to full control, meaning no suggestions will be auto-applied. And you can begin at this level or at the cautious level and then change as your trust in the automations grow. I'm going to switch to balanced, which applies routine clear-cut changes automatically. Let's hit save. And now let's return to that same issue. I'll close it and reopen it so we can trigger the automation again. Great, the workflow for our triage new issues has completed. Let's revisit the issue and see what has changed. I've got the issue open. I'm going to scroll down, and we can see that GitHub Actions added the bug label. We hover over the information icon. It says the report describes inconsistent existing behavior across pages, not a new capability request, which is the reasoning as to why that was applied. And then we have the low priority set here. And here it says the impact is limited to annoying UX inconsistency with no stated functional blocker. So we can see that our issue intent automation has worked. But how did we set this up, you may ask? Well, let's take a look at that right now. For our example, we used a GitHub agentic workflow, which, as you can see, allow us to create automations using natural language in Markdown. And ours is just three steps to classify the issue, suggest a priority, and include a short rationale. Up top, we have the workflow's front matter. And here's where we define the triggers. So in our case, when an issue is opened or reopened, permissions that our workflow has, the tools, and the safe outputs, which are the recommended actions a workflow can conclude with. And the secret sauce is in here. So for both the set issue type and set issue field actions, we are setting issue intent to true. Which means that we need to make sure the agent provides a rationale and confidence level for these actions to be done. We can now take a look at the last run of that workflow in our actions tab. I will scroll down, and I'm going to expand the safe outputs under the agent summary. And we can see indeed that both set issue type and set issue field were recommended for the workflow to conclude with. If I scroll down and load the summary of safe outputs, we can see that both the set issue type was success and set issue field. And those were applied to that issue that I reopened, 897. I've clicked on the agent job, and I've expanded ingest agent output. And here is exactly where we can see what issue intent set to true provides. We have that confidence and rationale, and we have it for both of the safe outputs. So set issue type and set issue field. For our demo, we used agentic workflows, but you can leverage co-pilot cloud agent automations, or build your own custom agents using supported GitHub MCP, REST, or GraphQL capabilities. This is just one example of the many tasks that issue intent can help you automate. I'll make sure to link docs with all the information that you will need, and please let us know any feedback that you have.
