Skip to main content
A workflow can only make the changes on this page, and each one waits for approval first. Under What it may change, a goal picks which kinds of change its runs may propose. Anything not picked stays read only. Every change runs as the person who created the goal, with that person’s role. Any member can create a goal, and a few changes below need a higher role. If the creator lacks or later loses the role a change needs, the change fails and nothing changes. Before it changes a CostGraph record, the agent reads the record to get its current state. After the change, it reads the record again to confirm the change took effect.

Budgets

These changes need Budgets under What it may change. The agent reads your budgets, with spend so far, forecast, and status, before and after each change. See Budgets.

Reports

A workflow can create, edit, and duplicate reports in any goal. Sharing, scheduling, and deleting a report need Reports under What it may change. The agent reads the report before and after each change.

Split rules

These changes need Cost allocation under What it may change. The agent reads your split rules and their targets before and after each change.

Tagging rules

Applying tagging rules needs Tagging rules under What it may change. It makes the rules of a queued virtual tag suggestion live, which changes how your spend is attributed. CostGraph applies exactly the rules you approved, and changes nothing if the suggestion changed since. The agent reads your virtual tags and their rules to confirm.

Prices

These changes need Pricing under What it may change, and an admin or owner as the goal’s creator. See On-prem pricing.

Billing exports

These changes need Billing export under What it may change, and an admin, owner, or billing admin as the goal’s creator. The agent reads your billing export connections and their meters before and after each change. See Billing exports.

Tickets

Filing a ticket needs Tickets under What it may change, and a connected Jira, Linear, or GitHub. A workflow creates a ticket for an anomaly or a recommendation, in a project or repository your connection allows. Each anomaly or recommendation gets at most one ticket in each tool. CostGraph records the ticket’s key and link on the run. See Jira, Linear, and GitHub issues.

Cloud changes

A workflow changes AWS resources through a connected AWS account with Let Workflows make approved changes turned on. The change must fall in a category the goal picked: Compute, Databases, Snapshots, or Storage. The agent inspects resources with read-only AWS calls before it proposes a change, and again afterwards to confirm it. The following AWS changes are available:
  • EC2: start or stop instances, change an instance’s type, change an EBS volume’s size, type, IOPS, or throughput, and add or remove tags.
  • Auto Scaling: change a group’s minimum, maximum, or target size.
  • EKS: change a managed node group’s scaling.
  • RDS: change an instance’s class or storage, and start or stop instances and clusters.
Cleanup needs Also allow cleanup on the AWS connection too. It lets a workflow delete unused EBS volumes, EBS snapshots, and RDS snapshots, release unused Elastic IPs, and set S3 bucket lifecycle rules.

Pull requests

A workflow can open a pull request in a repository the CostGraph GitHub App can reach. For example, it can lower a CPU request in a Helm values file. The change must fall in a category the goal picked: Compute, Databases, GPUs, Snapshots, or Storage. You approve the pull request’s title, repository, and instructions. After approval, a separate repository agent makes the change on a new branch and opens the pull request into the approved base branch. CostGraph checks every GitHub write against your approval, and never writes to the default branch or to .github/workflows files. CostGraph then checks the pull request on GitHub and records it on the run. Nothing merges on its own. Review and merge the pull request in GitHub, or close it to discard the change.

Connected services

A workflow can create, update, and delete resources in a connected service. It needs Integrations under What it may change, and the service must be one of the goal’s Connected tools. The following services are available:
  • DigitalOcean
  • Datadog
  • Vercel
  • Google Cloud
  • Hetzner
  • OVHcloud
  • Vultr
  • Linear
  • GitHub
Each change follows the goal’s approval setting. With Ask before every change, every change waits for you. With Allow any change, changes run without asking, up to the goal’s decision limit. See Approvals.

Resource marking

When a workflow creates a resource, CostGraph marks it with a tag or label. The same marking lets you find everything a workflow made. Some services don’t accept . or / in tag keys. There, CostGraph writes the key in the form the service allows: GitHub, Linear, and OVHcloud have no tag field for these changes, so those resources aren’t marked. Firewalls in DigitalOcean aren’t marked either. CostGraph always keeps the tags and labels you set. When a workflow updates a resource, it adds the marking only if the agent sets tags itself, so an update never replaces your own set.

Find what CostGraph made

Filter by the tag or label in the service’s own console or API:
  • To list everything CostGraph created, search for costgraph.ai/managed, or the form in the preceding table, with the value true.
  • To list what one run created, search for its costgraph.ai/run value. The run ID is on the run’s page.

Deletes

Before a delete, CostGraph reads the resource and checks for the marking. A marked resource follows the goal’s approval setting. A resource without the marking, or one CostGraph can’t read, always waits for your approval, even under Allow any change.

Next steps

Approvals

Review, approve, or reject a change.

Workflows from Graph AI

Start a workflow from chat, Slack, or MCP.