The same question keeps coming up in maintainer conversations: what do you do when the pull request queue fills with work written by agents?

It’s something Nicholas Tindle, founding AI engineer at AutoGPT, also deals with every day. I spoke with him in May for Maintainer Month. At the time of the interview, AutoGPT had over 180,000 stars and around 150 open pull requests. A big chunk of those pull requests were written by agents, including Copilot, OpenClaw, and AutoGPT’s own internal tooling, among others. Most maintainers I talk to have the same reaction: close the door. Turn off pull requests. Don’t tax the team with reviewing slop.

Nicholas saw an upside:

It’s basically somebody else paying for your compute.

Nicholas Tindle, founding AI engineer at AutoGPT

The way he sees it, if a contributor wants to spend their tokens improving your project, let them. Just make it so the only way through the door is the way that works for you.

Your docs aren’t the problem. Discovery is.

AutoGPT tried the obvious thing first. Better contributor guidelines. Better docs. A whole wiki dedicated to working with the repo.

None of it moved the needle. It turns out the tools aren’t going to go read your docs unless they’re told to. That’s the part a lot of us get wrong. We treat documentation like the agent will go find it. It won’t. Agents read what’s in front of them, at the level of the directory they’re working in.

So AutoGPT started putting instructions where agents look. First CLAUDE.md files, because Claude was generating pull requests without enough repository-specific context. The commit trailer made each one easy to spot, because they announced themselves in the commit trailer. Then they hit the next wall: Copilot and Codex ignore Claude files, because they’re not Claude. So they centralized the standard AGENTS.md and pointed Claude files at it.

Here’s the nuance I found most useful. AGENTS.md is scoped to a directory. A skill can be discovered outside that directory. (If you haven’t shipped one: a skill is an instruction file with a description that tells the agent when to load it. The agent scans descriptions up front and pulls in the full instructions when the task matches.)

AutoGPT’s AGENTS.md sits beside the code it governs. That placement matters as much as the instructions themselves.

If you’re writing backend tests and you think about doing front-end stuff, a skill may load dynamically. It’s not going to know what directory to go look in for an AGENTS.md file, but the skill can tell it that.

Their front-end engineer got tired of the same class of broken pull request, so they wrote a guide, and shipped it as a skill in the repo. The description contained trigger phrasing: write a Storybook test if your component lives in these folders. Now every harness that touches the repo discovers it automatically. The backend enforces its own version of the rule the same way: hit 80% coverage or don’t open the pull request.

Gates that actually work

These are the gates you can adapt for your project.

Enforce the pull request template, loudly. AutoGPT tells agents that pull requests not matching the template get closed automatically with zero hesitation. They built the tooling to actually do it, then found they didn’t need to run it. At AutoGPT, the rule changed agent behavior before the automation ever ran. The agents followed the template. Human contributors sometimes needed more room, which Nicholas treats as a feature:

If you don’t follow the template, I know you’re probably a person, and I’m going to be kinder.

The test plan trick. The template requires a test plan, and its wording casually mentions testing the pull request. That phrase triggers a skill called test PR, which installs agent browser (with permission), spins up the app, and executes the change. The agent set out to fill in a checkbox and ended up running the code.

They almost never get pull requests that don’t work anymore. What they get now is pull requests that work but don’t fit the roadmap, which is a much better problem to have.

Make CI a wall, not a suggestion. Codecov coverage thresholds are required checks. The agent opens the pull request, checks back a few minutes later, sees it can’t merge, loads the testing skill, and writes the tests. Nobody had to ask.

Use the CLA as a human detector. AutoGPT is dual licensed, but Nicholas argues every project should do this, MIT included. Signing requires a browser and a GitHub OAuth flow on a separate domain. Agents are bad at that today, and for good reason: most maintainers do not want an agent logged into GitHub in a browser with broad account access.

If your CLA is not signed after a week, we close the pull request with a comment that says sign the CLA, reopen when you’re done.

That gate works because it puts a human back in the loop. A CLA is one option. A code-of-conduct checkbox can do the same job.

Require a commit SHA before resolving a review thread. Some agents mark every review thread as resolved without touching the code. AutoGPT’s fix is a pr-address skill in the repo that declares the only valid sequence: fix, commit, push, reply, then resolve. The reply has to link the fixing commit, with the full SHA pulled from git rev-parse HEAD after committing, so the agent can’t recycle an old one. The skill even names the anti-patterns: “Acknowledged” is not a fix, and neither is citing a commit that doesn’t touch the flagged line.

The gate they turned off

When a check fails, AutoGPT had an agent read the run and comment on what broke. Their first version wired Claude Code into GitHub Actions and authenticated it inside the workflow, which meant one more broad credential living in CI. Running Copilot in the workflow gets the same result without that. Nicholas is a fan:

It’s unbelievable. I’m so happy I never had to bother with YAML ever again. I’m never writing a workflow for an action ever.

Then they turned the commenting off anyway. Their CI fails a lot, and a bot narrating every failure all day is not much better than the failure itself. The lesson is the restraint: keep what lowers the maintainer burden, shut off what becomes noise.

Four gotchas worth writing down

A bad AGENTS.md file is worse than no AGENTS.md. AutoGPT littered them everywhere at first and ended up polluting context, pulling the agent’s attention toward files that didn’t matter. If behavior gets worse, go read what you wrote.

The GraphQL API will rate limit you. When every tool on your team hits the CLI as an individual user, you hit the ceiling fast. Create a GitHub App and authenticate the CLI through it.

The heavy review tooling costs real money. Their pull request test rig clones the branch, spawns eight agents with different jobs, runs the whole stack, and uploads screenshots. It’s great. It’s also expensive enough that they now run it only on very small or very large pull requests.

Go audit your authorized apps. AutoGPT is part of the Secure Open Source Fund, and this was one of Nicholas’s takeaways from that work. Every tool they trialed and dropped left an authorization behind.

If you stop using a GitHub app, remove it from the authorized apps. Do a little audit right now after this stream and go see what you have. You’ll be surprised.

Logging in with GitHub is so automatic at this point that most of us have never gone back to look. I opened my settings during the stream. He was right.

Not everything is a gate

Two takeaways from Nicholas had almost nothing to do with tooling.

First: you don’t have to accept every pull request. Merging someone else’s LLM output is asymmetric. You do the upkeep, forever. Closing the pull request and building the fix yourself is a legitimate choice.

You can disable pull requests entirely. You can restrict issue creation to collaborators. Nicholas tied those controls back to the thing he kept coming back to in the interview: maintainers need knobs. Sometimes the right answer is fewer drive-by pull requests. Sometimes it’s issues only. Sometimes it’s “talk to us first.”

SQLite doesn’t take external code contributions. They take bug reports. That’s a valid open source boundary. Your project can have one too.

Second: when you close a pull request you’re going to rebuild yourself, add the contributor as a co-author if it makes sense. AutoGPT has around 800 contributors, so one more costs them nothing. For most people, the thing that matters is that their problem got fixed and somebody noticed they showed up.

What I’m taking back

Open source has always evolved by making collaboration explicit. Licenses made permissions explicit. Issues made work visible. Pull requests made review a shared practice. Instructions in the repo look like another step in that direction, though I’d hold that loosely. Nobody’s landed on the right shape yet. AutoGPT is on its third version, and it got there by shipping bad versions first and watching what agents did with them.

You still decide what belongs. You still set the bar. The difference is that more of that judgment can live next to the code, where your contributors and their agents already are.

Go look at the AutoGPT repo and read how they structured their agent files.

Then go join maintainers.github.com. I’d tell you that anyway because I work here, so take it from Nicholas instead:

You’ve got to go there. You’ve got to sign up. It gets you all the connections you want at GitHub. That’s where I learned about all this stuff, and where I share it.

It’s also where Tiny Wins gets prioritized, the weekly drip of small maintainer-requested improvements. Some of those asks have already shown up in the controls GitHub highlighted during Maintainer Month. It’s also where our product managers and engineers read feedback before anything ships. If you want a say in what the platform does for maintainers next, that’s the room. Your contributors are already AI-first. Put the rules next to the code before the next pull request lands.

The post Your contributors are AI-first now. Is your project? appeared first on The GitHub Blog.

Ask an architect almost any question and you’ll get the same answer: It depends. For years this answer has been the punchline of jokes about architects, but in an era when AI can generate a working service faster than you can describe it, “it depends” is one of the most important phrases in software. It marks the exact boundary of what these tools can and cannot do.

The First Law still holds

We’ve said for a long time that the First Law of Software Architecture is: Everything is a trade-off. Nothing about generative AI repeals that law. If anything, it enforces it more brutally than ever.

AI coding tools are extraordinary at answering “how” questions. How do I implement a saga pattern? How do I set up circuit breakers between these services? How do I paginate this API? These questions have answers that exist in the world in documentation, in open source code, in a decade of blog posts, and large language models have read all of it. Asking an LLM a “how” question is like asking a very fast librarian who has memorized the library.

Architecture questions are not “how” questions. They’re “should” questions, and “should” questions have a different shape entirely. The honest answers require knowing things that appear in no training: that your ops team is three people, that the CFO just froze cloud spend, that the last reorg left the payments team demoralized. An AI can enumerate the generic trade-offs of distributed architectures beautifully. What it cannot do is weigh them, because the weights live in your organization, not on the internet.

That’s the Second Law, incidentally: “Why is more important than how.” LLMs are “how” machines. Architects are “why” people.

Cheap code makes decisions expensive

There’s a tempting inference floating around: If AI makes building software easier, surely it makes architecture matter less. Our experience so far suggests the opposite. When code was expensive to produce, the cost of construction acted as a natural brake on bad decisions. A questionable design took months to build, and somewhere in month two, someone usually noticed. Now a team can stand up a fleet of services in a week. The brake is gone. It has never been easier to build the wrong thing quickly, at scale, with tests.

Think of AI as an amplifier. Point it at a sound structure and it accelerates you. Point it at a flawed one and it pours concrete over the flaw before anyone has time to object. The half-life of a bad architectural decision used to be measured in the time it took to implement; now the implementation arrives almost instantly, and you get to live with the decision for years.

This shifts where the leverage sits. When implementation is abundant, judgment is the scarce resource. Someone still has to decide where the service boundaries go, what “good enough” availability means for this system, and which architectural characteristics actually matter.

Judgment doesn’t come from reading

Here’s the uncomfortable part, and it applies to humans as much as machines: You cannot learn trade-off analysis by consuming content about it. We’ve written a fair amount of that content ourselves, so we say this with some authority. Books and talks give you the vocabulary. They don’t give you the judgment.

Judgment comes from making decisions and living with the consequences or at least watching someone experienced make them, asking why, and arguing about the alternatives. Every working architect we know learned the craft this way: apprenticed to messy, real problems, with feedback loops. The pattern catalog was the easy part. Knowing which pattern not to use, and why, and being able to explain that to a skeptical VP that took years of reps.

This is also, not coincidentally, exactly what today’s AI lacks. A model trained on the world’s code has seen millions of decisions but almost none of the consequences. The post mortem that traces an outage back to a boundary drawn wrong in 2019 rarely makes it into the training data, and even when it does, it isn’t connected to the pull request that caused it. Architecture’s feedback loops are measured in years. That’s precisely the kind of learning that can’t be scraped.

Where this leaves engineers

If you’re a developer watching AI absorb more of the implementation work, the strategic question isn’t whether your current tasks will change but where to move on the value chain. Our answer is to move toward the decisions. Toward the trade-offs, the constraints, the “it depends.” That territory isn’t shrinking; it’s growing, because every AI-accelerated team needs someone who can tell the amplifier where to point.

The good news is that this is learnable. Not from a book alone, and certainly not from an LLM, but the way it’s always been learned: by practicing architectural thinking on real problems, with experienced people looking over your shoulder and asking why. We’ve spent the last several years teaching it that way, most recently in a six-week cohort format that works less like a course and more like a short apprenticeship in making and defending architectural decisions. (Details are on the O’Reilly live events page, if you’re curious.)

However you pursue it, pursue it. The machines have gotten very good at “how.” The career-defining skill of the next decade is being the person in the room who can answer “should,” who knows that the real answer starts with “It depends,” and can finish the sentence using their brain alone.

This is the second post in our series on the Microsoft agent platform. Here we dive deep into building autonomous agents, the development experience, the Microsoft Agent Framework, tool design patterns, and how the GitHub Copilot SDK brings conversational AI to your agent system.

All examples reference the FibreOps repository, an autonomous fibre outage response system demonstrated at Microsoft Build BRK241.

The Microsoft Agent Framework

The Microsoft Agent Framework (now GA) provides a unified programming model for building agents. It supports multiple backends through a single .run() contract:

• Hosted — FoundryAgent connected to a Prompt Agent published to Microsoft Foundry Agent Service.
• Foundry — Agent + FoundryChatClient with the definition resolved locally (ideal for prompt iteration).
• Local — Deterministic LocalAgent for offline development and testing.

This design means your orchestration code never changes regardless of where the agent runs. The factory pattern in FibreOps selects the backend at startup:

# src/fibreops/agents/factory.py — simplified
from agent_framework_foundry import FoundryAgent
from agent_framework import Agent, FoundryChatClient

def build_agent(role: str, backend: str, config: Config):
    if backend == "hosted":
        return FoundryAgent(agent_id=config.foundry_agents[role])
    elif backend == "foundry":
        return Agent(
            instructions=get_instructions(role),
            chat_client=FoundryChatClient(endpoint=config.endpoint),
            tools=get_tools(role),
        )
    else:
        return LocalAgent(role=role)

Set FIBREOPS_AGENT_BACKEND to override the backend, or leave it as auto for intelligent detection.

Designing Role-Specialised Agents

FibreOps demonstrates a key pattern: role specialisation. Rather than one monolithic agent, the system uses three focused agents, each with a clear responsibility boundary:

Why Role Specialisation?

• Focused system prompts — Each agent has a tightly scoped instruction set, reducing hallucination and improving reliability.
• Independent evaluation — You can score each agent separately against role-specific criteria.
• Parallel development — Teams can iterate on agents independently.
• Selective upgrade — Swap one agent's model or implementation without touching others.

Tool Design: Typed Python Functions

Tools in the Microsoft Agent Framework are typed Python functions that the runtime supplies to the hosted agent definition. FibreOps demonstrates several tool categories:

Knowledge Tools

# src/fibreops/tools/knowledge.py — simplified
def sop_lookup(node_id: str, signal_type: str) -> dict:
    """Retrieve the Standard Operating Procedure for a given signal type.
    
    Args:
        node_id: The fibre node identifier (e.g., FN-LDN-001)
        signal_type: The type of signal (loss_of_light, high_ber, signal_degradation)
    
    Returns:
        SOP with steps, escalation path, and estimated resolution time.
    """
    # Load from local markdown SOPs or Foundry IQ
    ...

def web_iq_search(query: str, *, limit: int = 5) -> list[dict]:
    """Search public web for context relevant to the incident.
    
    Grounding against roadworks, weather, power outages, splice guidance.
    Falls back to deterministic fixtures when endpoint is unset.
    """
    ...

def work_iq_search(query: str, *, limit: int = 5) -> list[dict]:
    """Search enterprise knowledge for context relevant to the incident.
    
    Site surveys, SLA tiers, competency matrix, MTTR trends.
    """
    ...

Integration Tools

# src/fibreops/tools/teams.py — simplified
def post_outage_notice(
    incident_id: str,
    node_id: str,
    severity: str,
    summary: str,
    engineer: str | None = None,
) -> dict:
    """Post an Adaptive Card outage notice to the configured Teams channel.
    
    If TEAMS_WEBHOOK_URL is not set, appends to state/teams_outbox.jsonl
    for offline review.
    """
    card = build_adaptive_card(incident_id, node_id, severity, summary, engineer)
    if config.teams_webhook_url:
        requests.post(config.teams_webhook_url, json=card)
    else:
        append_to_outbox(card)
    return {"status": "posted", "incident_id": incident_id}

Design Principles for Agent Tools

• Typed parameters with docstrings — The runtime uses type hints and docstrings to generate the tool schema for the LLM.
• Graceful degradation — Every tool works offline by falling back to local fixtures or file-based state.
• Idempotent where possible — Tools that create resources return existing records if called with the same parameters.
• Observable — Every tool invocation emits an OpenTelemetry span for tracing and debugging.

The Orchestrator Pattern

The orchestrator drives signals through the agent pipeline. It is deliberately simple — a linear flow with error handling:

# src/fibreops/orchestrator.py — simplified
async def handle_signal(signal: TelemetrySignal) -> RunResult:
    """Process a telemetry signal through the agent pipeline."""
    
    # Stage 1: Incident Analysis
    analysis = await incident_agent.run(
        f"Analyse this signal: {signal.model_dump_json()}"
    )
    
    # Stage 2: NetOps Coordination
    coordination = await netops_agent.run(
        f"Coordinate response for: {analysis.summary}"
    )
    
    # Stage 3: Field Dispatch
    dispatch = await dispatch_agent.run(
        f"Dispatch engineer for incident: {coordination.incident_id}"
    )
    
    return RunResult(
        signal=signal,
        analysis=analysis,
        coordination=coordination,
        dispatch=dispatch,
    )

The orchestrator honours the same contract regardless of backend — hosted, foundry, or local — because all backends implement await agent.run(prompt).

GitHub Copilot SDK Integration (GA)

The GitHub Copilot SDK enables conversational interaction with your agent system. FibreOps implements FibreOpsCopilotClient with the same interface as github​/copilot-sdk:

# src/fibreops/sdk/__init__.py — simplified
from fibreops.sdk.client import FibreOpsCopilotClient

client = FibreOpsCopilotClient()
session = client.create_session()

# Query agent status
response = session.send_and_wait("status")
print(response.text)   # Human-readable summary
print(response.data)   # Structured JSON

# Inject a telemetry signal via conversation
response = session.send_and_wait(json.dumps({
    "signal_id": "sig-demo",
    "node_id": "FN-LDN-001",
    "signal_type": "loss_of_light",
    "severity": "critical"
}))

The adapter routes prompts by shape:

• JSON signal-shaped dicts — Forwarded to the orchestrator for processing.
• Free-form text — Answered by a deterministic responder (help, status, nodes, engineers, optimiser, dispatch).

Drive it from the terminal:

python -m fibreops.demo chat "help"
python -m fibreops.demo chat "status"
python -m fibreops.demo chat '{"signal_id":"sig-demo","node_id":"FN-LDN-001","signal_type":"loss_of_light","severity":"critical"}'

Or hit the embedded HTTP endpoint when the NOC console is running:

Invoke-RestMethod -Method Post http://127.0.0.1:8800/sdk/chat -Body '{"prompt":"status"}' -ContentType application/json

Development Workflow with Foundry Toolkit for VS Code

The Foundry Toolkit for VS Code provides an integrated development experience:

1. Author prompts — Edit system instructions with live preview and token counting.
2. Test locally — Run against the foundry backend with FoundryChatClient pointing at your development model.
3. Iterate fast — The foundry backend resolves definitions locally, so prompt changes take effect immediately without republishing.
4. Publish when ready — python -m fibreops.demo publish creates hosted Prompt Agents in Foundry.

Multi-Model Support

The Microsoft Agent Framework supports multiple models. FibreOps defaults to gpt-4.1-mini (the model available in most demo Foundry accounts), but any chat-completions deployment works:

# .env
AZURE_AI_MODEL_DEPLOYMENT=gpt-4.1-mini  # or gpt-4o-mini, gpt-4o, gpt-4.1

The framework also supports Claude Code connectors and Magentic-One for multi-agent collaboration scenarios.

Testing Strategy

FibreOps demonstrates a layered testing approach:

• Unit tests — Test tools in isolation with mocked dependencies.
• Local backend tests — Run the full pipeline with LocalAgent for deterministic assertions.
• Integration tests — Run against real Foundry agents with pytest -q.
• Rubric evaluation — The optimizer scores every run against defined criteria.

# Run the test suite
.\.venv\Scripts\python.exe -m pytest -q

Key Takeaways

• The Microsoft Agent Framework provides a unified .run() contract across hosted, foundry, and local backends.
• Role specialisation keeps agents focused, testable, and independently evolvable.
• Tools are typed Python functions with docstrings — the runtime generates schemas automatically.
• The GitHub Copilot SDK (GA) enables conversational interaction with any agent system.
• Graceful degradation means the entire system works offline for development.
• The factory pattern lets you switch backends without changing orchestration code.

Next Steps

• Clone the FibreOps repository and run python -m fibreops.demo --signals 3
• Microsoft Agent Framework documentation
• Next in this series: Running Hosted Agents in Microsoft Foundry Agent Service

As a GitHub administrator, you already have a strong place to start when somebody asks, “Why did our AI spend go up?” In Metered usage, you can see the change, choose the period, and group the data by organization or cost center.

 

That first investigation often leads to questions that are specific to your company. Finance may want a month-end report based on its own reporting calendar. An engineering leader may want to see whether an increase is spread across a team or concentrated among a few people. Answering those questions once is useful; answering them repeatedly calls for a reusable approach.

 

Use each surface for what it does best

 

The GitHub admin UI shows you where to look and gives you the controls to respond. The Billing Usage API helps you answer the recurring questions that are specific to your company. Neither replaces the other.

 

Together, they give administrators a practical loop: spot the change in Metered usage, understand it through a reusable API-powered view, and act with a targeted budget. That means better cost control without treating every user or team as the problem.

 

Let’s walk through this better-together approach using a common example: AI spend starts to rise, but the reason is not yet clear.

 

The question: Spend is up, but what is driving it?

 

Imagine that finance notices an increase in AI spend before the next close. It could be a sign that more developers are getting value from Copilot. It could also be one workload using far more than expected. At this point, nobody knows, and a broad restriction would be premature.

 

The GitHub administrator needs to help finance and engineering answer three practical questions:

 

- Which part of the business is driving the increase?

- Is the spend concentrated among a few users or broadly distributed?

- Which control should change without disrupting everyone else?

 

The goal is not simply to reduce a number. It is to understand the increase well enough to protect useful work while addressing anything unexpected.

 

1. Start in the admin UI: Find the increase

 

The admin UI is the natural place to begin because it lets you explore the data before you decide what kind of report or control you need. Open **Billing and licensing > Metered usage** and select the relevant reporting period.

 

This first check matters. It confirms that the increase is real, shows when it happened, and gives you a shared starting point for the conversation with finance and engineering.

 

 

Fig 01: Metered usage establishes the increase and the period that needs investigation.

 

Narrow the increase by organization

 

An enterprise total tells you that spend changed, but not where to look next. Group the usage by organization to see which part of the enterprise contributed most to the increase.

 

 

Fig 02: Organization grouping narrows an enterprise-wide increase to an accountable business area.

 

Suppose the octodemo organization stands out. You now know where to continue the investigation and which leaders can add context. You do not yet know whether the spend is justified, and that distinction matters. The increase could come from successful Copilot adoption, a migration, a seasonal workload, or an automated process that needs attention.

 

Connect the increase to a cost center

 

An organization can contain several teams, programs, and budgets. Grouping by **cost center** takes the investigation one step closer to the people who understand the work behind the spend.

 

 

Fig 03: Cost-center grouping identifies the financial owner of the increase.

 

In this scenario, octodemo-org-cc has the largest increase. In only a few clicks, the admin UI has taken us from an enterprise-wide signal to the cost center that needs a closer look. For a one-time question, this may be enough.

 

Now imagine that finance asks for the same analysis every month, with a fixed reporting period and a ranking of spend by user. That is the point where the API adds value. It does not replace the investigation you just completed; it helps you repeat and extend it.

 

2. Continue with the API: Answer the repeatable question

 

The Billing Usage API gives you access to the data behind a more tailored report. You can use filters to match the period finance cares about, focus on the cost center you found in the UI, and build a view that can run again tomorrow or next month.

 

 

Fig 04: Billing usage endpoints and time filters provide the inputs for a reusable report.

 

Define the reporting question first

 

Before writing code, state the question the report needs to answer. In this example, it is:

 

> Which users in the selected cost center account for the most net spend during this reporting period?

 

That one question keeps the report focused. It also determines the workflow:

 

1. List the organization's members to establish the candidate users.

2. Resolve which members belong to the selected cost center.

3. Query organization AI credit and premium-request usage for those users and the selected period.

4. Combine the results into a per-user total.

5. Rank users and aggregate the result by cost center.

 

The prototype uses year, month, and optional day filters so the output matches the finance period. It also accepts a cost-center filter. Because the admin UI has already pointed us to `octodemo-org-cc`, there is no reason to start with every member of the enterprise.

 

Understand the per-user query pattern

 

There is one API behavior to understand before building the report. The organization billing endpoints return an aggregate when the user filter is omitted. To create a spend-by-user ranking, the workflow makes a filtered request for each selected user and usage type.

 

For example, this request asks for Eve's AI credit usage in July 2026:

 

curl -L \ -H "Accept: application/vnd.github+json" \ -H "Authorization: Bearer $GITHUB_TOKEN" \ -H "X-GitHub-Api-Version: 2026-03-10" \ "https://api.github.com/organizations/octodemo/settings/billing/ai_credit/usage?year=2026&month=7&user=eve"

 

The response contains one or more usage items, with amounts such as `grossAmount`, `discountAmount`, and `netAmount`. The prototype adds the `netAmount` values to calculate Eve's AI credit total for the period. It then runs the equivalent premium-request query and combines the two totals.

 

We can now see one user's contribution during the same period we investigated in the UI. Repeating the request for the members of the selected cost center gives us the ranking that finance asked for.

 

For a production workflow, a few practical details matter:

 

- Limit the candidate list to the cost center under investigation.

- Paginate organization membership and cost-center results.

- Use bounded concurrency instead of sending every request at once.

- Record partial failures rather than silently treating them as zero spend.

- Keep an audit record of when the data was pulled and transformed.

 

For a daily check, the report can use a narrow period and write a timestamped output. At finance close, the same workflow can produce the month-end rollup. The question stays the same; only the reporting window changes.

 

Reveal concentration that totals can hide

 

The result is a custom Spend by User view that brings the organization, cost center, reporting period, AI credit usage, premium-request usage, and total net spend into one place.

 

 

Fig 05: A company-specific dashboard exposes per-user concentration inside the selected cost center.

 

In the illustrative data, the octodemo organization has 22 users and $3,651 in total net spend for July 2026. The octodemo-org-cc cost center accounts for $2,700 of that amount. Two users stand out:

 

 

Together, Adam and Eve account for $2,500 of the $2,700 attributed to that cost center. That is approximately 93% of its total in this example.

 

These figures are demonstration data, but they show why the extra view is useful. Instead of reacting to a $2,700 cost-center total, the administrator can talk to the owners of two workloads and understand what the spend supported.

 

Concentration does not automatically mean waste. Adam and Eve may be doing approved, high-value work. The dashboard tells the business where to ask the next question; the people involved provide the context needed to answer it.

 

3. Return to the admin UI: Choose the right control

 

The API has helped us understand the increase, but it does not make the decision for us. Return to Billing and licensing > Budgets and alerts to review the available controls and choose the narrowest one that fits what you learned.

 

Fig 06: Budget scopes turn the investigation into a targeted governance decision.

 

Set a cost-center user-level baseline

 

A cost-center user-level budget applies the same per-user amount to every current and future member of that cost center. This is useful when the group needs a different baseline from the rest of the enterprise.

 

For example, the administrator might give octodemo-org-cc additional per-user headroom because its work legitimately uses more AI credits. This avoids raising the universal user-level budget for everyone.

 

A user-level budget counts both included and paid AI credit usage. It is always a hard stop for the individual. It does not reserve part of the shared pool, and it does not replace the cost center's paid-usage budget.

 

Preserve justified exceptions

 

If Adam or Eve has an approved role that requires more capacity, an individual user-level budget can replace the cost-center baseline for that person. The exception stays limited to the person who needs it instead of increasing the budget for the whole cost center.

 

 

Fig 07: Cost-center baselines and individual overrides preserve useful work without widening access for everyone.

 

The precedence is straightforward:

 

1. An individual user-level budget overrides the cost-center user-level budget.

2. The cost-center user-level budget overrides the universal user-level budget.

 

In practice, you can set a universal baseline, add more headroom for a cost center with a clear business need, and use individual overrides for documented exceptions.

 

Why the UI and API work better together

 

At this point, the better-together pattern becomes clear:

 

- Metered usage supports interactive discovery.

- Billing Usage API supports repeatable, company-specific analysis.

- Budgets and alerts supports targeted policy decisions.

 

Each surface does the job it is best suited to do. The UI makes it easy to explore and manage GitHub. The API lets you repeat a company-specific analysis without rebuilding it by hand. Used together, they give finance, engineering, and administrators the same evidence before a control changes.

 

Make it part of the operating rhythm

 

A useful dashboard should lead to a useful conversation. Decide who receives the report, how often they review it, and what happens when a user or cost center stands out.

 

For example:

 

- Run a daily pull to detect unusual changes early.

- Produce a month-end rollup aligned to finance close.

- Route cost-center summaries to the relevant business owner.

- Review high-consumption users with engineering before changing limits.

- Record approved individual overrides and revisit them regularly.

 

Over time, the conversation can move from “Who spent this?” to “What outcome did this spend support, and does the current policy still fit?”

 

When the same users repeatedly appear at the top, leaders can inspect the workload, remove waste, validate business value, or approve more capacity. When usage becomes broadly distributed, the cost-center baseline may need adjustment instead. The report makes those patterns visible over time.

 

The better-together workflow at a glance

 

The story above introduces each surface when it becomes useful. This table summarizes their roles.

 

 

The practical takeaway is simple: begin with exploration, automate only the question worth repeating, and adjust policy after the data has context. That sequence keeps governance precise while preserving useful AI work.

 

Learn more

 

- REST API endpoints for billing usage

- List organization members]

- Budgets for usage-based billing]

- Using cost centers to allocate costs

 

Today we released SQL Server Management Studio (SSMS) 22.9.0, with updates to GitHub Copilot, the connection experience, Database DevOps, SQL formatting, and more. As always, we recommend that users update to the latest release when it’s available, as it’s the generally available and supported release. You can view the release notes for more details about the new features and fixes. We continue to monitor customer feedback and add functionality with each release, so if you’re using GitHub Copilot, Database DevOps, or SQL formatting, we appreciate you trying out what’s new and reporting any issues or requests on our feedback site.

GitHub Copilot in SSMS: Changes to Ask Mode

We've made an important behavior change to Ask Mode in GitHub Copilot in SSMS. Ask Mode is intended to be a read-only experience for getting guidance and script help, and we've heard clear feedback that users expect that experience to stay read-only regardless of credential scope.

To align with that expectation, Ask Mode no longer executes arbitrary queries, whether generated by the model or provided in chat. Instead, Ask Mode now returns T-SQL scripts in its responses for you to review and run yourself.

For most Ask Mode scenarios (like writing, refining, and understanding scripts) this should feel familiar. Copilot can still explore schema context to provide useful guidance, but it will not execute scripts to retrieve user data. This creates a clearer separation between advisory and execution experiences, keeps you in control, and sets a more intuitive boundary as we continue toward broader Agent Mode availability.

GitHub Copilot in SSMS: Agent Mode Progress

Agent Mode continues to evolve in preview. In 22.9, we've added a set of tools that allows GitHub Copilot to interact with connected objects in Object Explorer. This gives Agent Mode more awareness of the objects you're working with and lets it participate more naturally in workflows that start from Object Explorer.

Updates to the Connection Dialog

Toggle between horizontal and vertical layouts

This release brings a whole bunch of updates and improvements to the Modern Connection Dialog! These changes aim to make the connection dialog more flexible and accessible:

• Azure and Fabric browsing now supports subscription search and filtering. This applies when browsing Azure resources and workspaces as well as Fabric resources.
• The Browse tab now includes search and filtering.
• You can now browse Azure SQL Managed Instances.
• The server name field is now an editable drop-down menu, improving keyboard accessibility.
• The dialog now supports a horizontal layout.
• Hostname in certificate is available in the default connection properties view.
• Connection import and export is now supported.
• The maximum number of recent and favorite connections has increased to 60.
• Available SSMS themes are supported more consistently throughout the connection experience.

These changes make it easier to find resources, preserve connection setups, and work with the connection dialog in the way that best fits your screen and workflow.

Quickly select your connection with the Server Name drop down field.

Database DevOps (preview)

Database DevOps in SSMS continues to evolve. In 22.9, the Add Database Reference dialog has a refreshed UI with improved theme support and additional reference types. You can now choose among four reference types:

• dacpac
• database project
• NuGet package
• system database

We've also updated SqlProj document tab names to remove the confusing - not connected suffix. See Document tab names in SSMS sqlproj are not good.

SQL Formatter (preview)

The SQL Formatter preview now gives you more control over formatting and a clearer way to understand the result before applying it:

• Choose whether indentation uses tabs or spaces.
• Configure trailing comma style.
• Choose whether column aliases use the AS keyword, an equals sign, or preserve the original style.
• Insert a new line before the ON keyword.
• Preview before-and-after T-SQL in the SQL Formatter settings dialog.
• The Include Semicolons setting has also been removed.

These options are a starting point for making formatting work better across different SQL styles, and we welcome your feedback as the preview continues to improve.

Lots of Bug Fixes!

As always, the full list is in the release notes, but a few fixes that are worth calling out include:

• Connection dialog — You can now save multiple connection strings with different application intent values. See Unable to save 2 connection strings with different application intents using the new connect screen.
• Object Explorer — Some users could not view SQL Server Agent details despite having the proper permissions. That issue is fixed.
• Schema Compare — Fixed several issues involving comment-only differences, schemas that incorrectly showed no differences, the Ignore Comments setting, stored procedure formatting, and whitespace highlighting in the diff viewer. See Schema Compare Preview fails to display comment-only differences in front of create views, Schema compare shows no differences between different database schemas, Compare Schemas ignores comment differences regardless of Ignore Comments setting, When comparing stored procedures in Schema Compare, they are reformatted, and Schema Compare incorrectly flags differences in whitespace in table comparison.
• SQL Agent — Users no longer need EXECUTE permission on xp_instance_regread just to view or run SQL Server Agent jobs. See SQL Agent blocks AD groups from viewing jobs without xp_instance_regread access.
• SQL Formatter — Fixed an issue that merged CONSTRAINT lines into the preceding commented line. See SQL Formatter merges CONSTRAINT line into preceding -- comment.
• Results Grid — Toolstrip labels no longer truncate in some languages. See Visibility counts completed rows.
• Theme — The SSMS theme no longer reverts to Cool Breeze after restarting. See SSMS theme setting reverts from Dark to Cool Breeze after restart.
• Toolbar — Fixed an issue that caused several toolbar icons to disappear. See SSMS toolbar icons missing for query controls and execution plan buttons.

 

Download audio: https://episodes.castos.com/5e2d2c4b117f29-10227663/2570055/c1e-zo9ob3orrpa0xxok-9j227n25cw2m-loicmg.mp3