Major Tom is an AI cloud cost agent built by Blocks that runs inside Slack. The AWS FinOps Agent is an AI agent that AWS released in public preview on June 9, 2026, which answers cost questions in natural language and sits on top of AWS’s existing cost services. In June 2026 I tested the two against each other by putting the exact same questions to both, taken from the sample set AWS ships to demonstrate the FinOps Agent.
The clearest result of the test was a factual one. The AWS FinOps Agent recommended downsizing two EC2 instances that had already been terminated. It cannot check live instance state, so it had no way to know they were gone. Major Tom checked the same two instances, reported them as terminated by EKS Auto Mode, and explained why.
My read, and I should be explicit that I am the founder of Blocks and therefore not a neutral party: the two agents are closely matched on analysis and diverge on acting on the results. The AWS FinOps Agent fits large organisations with dedicated FinOps teams who analyse and report on spend. Major Tom is built for startups that want to get from finding a problem to fixing it.
How I tested this
This is a hands-on comparison rather than a feature-table review. I took half of the sample questions AWS ships to demonstrate the FinOps Agent and put each one, word for word, to both agents. The dollar figures throughout come from my own AWS accounts in May and June 2026. Each section below first reports what both agents returned, then gives my own read of the result.
Monthly cost analysis: both agents returned the same numbers
Question tested: compare last month’s AWS cost with the month before.
Both agents returned the same figures. Total AWS spend in May 2026 was $9,087.60, down $185.19 (2.0%) from April’s $9,272.79. Both correctly noted that the small overall decline hid large moves in opposite directions: RDS rose $572.27 (64%), from $892.36 to $1,464.63, while EC2 Compute fell $244.17 (15%). Both identified RDS as the first service to investigate.
The agents differed in emphasis. Major Tom led with the services that changed most in absolute terms. The AWS FinOps Agent led with the services carrying the highest absolute cost.
My read: I preferred Major Tom’s emphasis, because a monthly review exists to surface the biggest moves up and down, and those are the ones you investigate first. Major Tom’s answers were also more concise and it offered prefilled follow-up buttons (which my lazy self really appreciates). This is a preference, not a defect in either tool.
Drilling into the RDS spike: both agents traced it to the same cause
Question tested: what drove the RDS increase?
Both agents reached the same conclusion. The RDS rise was driven almost entirely by Aurora Serverless v2, which nearly doubled from $237.88 in April to $546.39 in May, an increase of $308.51 (130%). The daily pattern was a gradual ramp: around $11 a day in late April, rising to $23 to $30 a day through May, with a step up around May 26. Broken down by instance, the single largest consumer was one Aurora PostgreSQL cluster, which accounted for 63.5% of Aurora Serverless v2 cost, burned over $234 in 14 days, and was on track for roughly $500 a month.
My read: on pure analysis the two agents are very close. Neither made an error here.
EC2 rightsizing: the AWS FinOps Agent recommended changes to terminated instances
Question tested: find EC2 rightsizing opportunities and produce a report.
The two agents recommended different actions. Major Tom recommended reserved instances and a Graviton migration, and its report headlined savings of around $631 a month, roughly $7,900 a year, across six instances. The AWS FinOps Agent instead recommended downsizing two specific instances, i-058cf51e6980caaf0 and i-01ff514a45e29b93a.
Both of those instances had already been terminated on June 10, 2026 by EKS Auto-Scaling. The AWS FinOps Agent could not detect this, because it lacks permission to check live instance state. Its rightsizing recommendations come from AWS Cost Optimization Hub and AWS Compute Optimizer, which work from historical cost and usage data rather than a live check of whether the instance still exists. When I put the same two instance IDs to Major Tom, it reported them as terminated, named EKS Auto-Scaling as the cause, and explained that the cluster had scaled down automatically.
On report formatting, the AWS FinOps Agent did better. It produced a clean HTML report that was ready to share with a manager. Major Tom returned its HTML as raw code in the chat, and its conversational summary only appeared after I asked for it.
My read: the formatting gap is real and I am not going to wave it away, but the accuracy gap matters more. A recommendation to act on a resource that no longer exists is the kind of error that loses a user: you take the finding to your manager, you get approval, and then you find the instance is gone. The underlying cause is a hard permissions problem and I have sympathy for it, but the user does not care about the cause. They need the recommendation to be correct. That is the reason we built live-state verification into Major Tom.
Deleting an idle RDS instance: both found it, Major Tom did the checks
Question tested: find idle RDS instances and explain how to delete them.
Both agents found the same idle instance: test-db-large, a db.t4g.micro running PostgreSQL, with zero connections over the past 24 hours and a maximum CPU of 17.7% over 14 days, costing about $247 a month. Both supplied the CLI command to delete it.
The agents differed in how much of the work they did. Major Tom checked the blast radius, looked at active connections, confirmed how the instance was managed, and detected that it carried no infrastructure-as-code tags, which is why it recommended a direct CLI command. It also included a ready-made prompt for handing the task to a coding agent. The AWS FinOps Agent listed, in the abstract, the checks a user should run before deletion, and left those checks to the user.
My read: I preferred Major Tom here, because it gathered the relevant information itself and let me start the deletion straight away, rather than describing what I should go and verify.
A scheduled, recurring S3 cost check: the AWS FinOps Agent did it, Major Tom could not
Question tested: check my S3 costs every day at 12 PM EST.
The AWS FinOps Agent set this up on its own. It let me define the report I wanted, wrote the schedule and the prompt, and configured the recurring task itself. This fits its design: scheduled, recurring cost reports are a capability AWS ships with the agent. Major Tom could not. As of this test it produces only a small set of system-generated, static recurring reports, and it could not create the custom scheduled task I asked for.
My read: this round clearly goes to the AWS FinOps Agent. Recurring reports and scheduled tasks are the biggest gap in Major Tom today. Our users have asked for the feature, so I expect it to arrive, but as of this test the FinOps Agent was the better tool for the job.
Why execution, not analysis, is where FinOps breaks down
It is worth stepping back from the two agents for a moment, because the broader FinOps data explains why the split between them matters.
The FinOps Foundation’s State of FinOps report has found, that workload optimization and waste reduction is the single top priority for practitioners, named by about half of them. The recommendations themselves are not the scarce resource. The native hyperscaler tools already produce long lists of rightsizing and idle-resource findings. The hard part is acting on them. Capturing a saving means an engineer has to confirm that a change will not harm performance or reliability, and then actually make it, which is slow and competes with shipping product.
The gap is not new. In earlier State of FinOps reports, getting engineers to take action on recommendations ranked as the top priority.
This is the lens I would read the comparison through. Both agents are good at the analysis, which the data suggests is no longer where teams lose ground. They differ on what happens next: whether the agent verifies a finding and hands you something you can act on, or whether it produces a recommendation that you then have to check and execute yourself.
Source: FinOps Foundation, State of FinOps report.
The bottom line: execution is the deciding factor
This section is my conclusion rather than a measured result.
Across the questions I tested, the two agents were close on analysis and far apart on execution. If the FinOps data is right that finding savings is no longer the bottleneck and acting on them is, then the dimension that decides a cost agent’s value is the one where these two differ most.
On that dimension I lean toward Major Tom, and not only because Blocks builds it. The single clearest result of the test was an execution failure: the AWS FinOps Agent recommended acting on two resources it could not verify, and they were already gone. That is the kind of error that, once repeated, teaches a team to stop trusting the tool, and trust is what turns a recommendation into an action that actually gets taken. Major Tom checked the same resources and told me the truth.
“The value of an agent is speed. You get there by trusting what it says and letting it do the work, so you only have to sign off. Major Tom delivers on both.”
I am not going to pretend the picture is one-sided. The AWS FinOps Agent is better at reporting, and it set up a recurring scheduled task that Major Tom cannot yet match. For a large organisation whose FinOps function is mostly about analysing and reporting on spend, that may be the deciding feature, and it is a strong tool for that job.
But for most teams, where the real constraint is getting from a finding to a fix, I would choose the agent that is built to be acted on. Pick the AWS FinOps Agent if your priority is detailed reporting and scheduled analysis. Pick Major Tom if your priority is execution, which for most teams is the part that decides whether the savings ever land.
FAQ
What is a FinOps agent?
A FinOps agent, also called a cloud cost agent, is an AI agent that answers natural-language questions about cloud spend, investigates cost changes, and surfaces or carries out cost optimizations. The name comes from FinOps, short for financial operations, the practice of managing cloud cost. The agentic version of the category took shape in 2026, with agents that work inside tools like Slack rather than in a separate dashboard. Major Tom and the AWS FinOps Agent are two examples.
What is the AWS FinOps Agent?
The AWS FinOps Agent is AWS's agentic AI cost tool, released in public preview on June 9, 2026 at FinOps X. It answers cost questions in natural language, investigates cost anomalies by correlating them with AWS CloudTrail events, generates scheduled reports in HTML, PDF and PowerPoint, and can open Jira tickets for the responsible owner. It is built on top of AWS Cost Explorer, Cost Anomaly Detection, Cost Optimization Hub and Compute Optimizer, and it surfaces its optimization recommendations from the latter two. During the preview it runs only in the US East (N. Virginia) region and is free to use, though the underlying AWS APIs it calls are charged as normal. Source: AWS, Announcing the public preview of AWS FinOps Agent.
What is Major Tom?
Major Tom is a DevOps agent built by Blocks. It runs inside Slack and surfaces cost, security and reliability findings. Its defining design choice is that it focuses on actioning its findings to allow customers to fix issues in less than a minute.
What is the difference between Major Tom and the AWS FinOps Agent?
Both are AI cloud cost agents that answer cost questions and surface savings, and in this test they were closely matched on the analysis itself. The difference is what happens after the finding. The AWS FinOps Agent is built mainly to analyse spend, investigate anomalies and produce reports, and it leaves the action to the user. Major Tom is built to be acted on: it verifies a resource's live state, checks blast radius, how the resource is managed etc. AWS aimed its agent at large organisations with dedicated FinOps teams, while Major Tom is aimed at startups that want to fix problems rather than only report them.
Can the AWS FinOps Agent help with execution?
Partly. It is good at the steps leading up to execution: it produces clean reports, opens Jira tickets for the responsible owner, and gives detailed check lists. What it does not do is run all the checks on behalf of the users. In one case, this resulted in a deletion recommendation of two already deleted EC2 instances.
Which cloud cost agent is better for a startup?
For a startup that wants to act quickly and trust the recommendations without checking each one by hand, Major Tom fit better in this test. For a large organisation that needs detailed reporting and scheduled analysis, the AWS FinOps Agent is a strong choice.
How much does the AWS FinOps Agent cost?
During its public preview the AWS FinOps Agent is free to use, though the underlying AWS APIs it calls, such as Cost Explorer, are billed as normal. AWS has not published its pricing for after general availability. Its sibling agents give a strong hint of the likely model, since both are billed by active time and metered per second: the AWS DevOps Agent costs $0.498 per agent-minute, about $30 per hour of active work, and the AWS Security Agent costs $50 per task-hour. On that pattern, expect the FinOps Agent to move to per-minute, usage-based pricing once the preview ends.
How much does Major Tom cost?
Major Tom is free for Blocks members. There is no per-minute or usage-based charge for it, unlike the metered model AWS uses for its own agents.
Dr. Andreas Schroeter
Company builder and co-founder of Blocks. Twenty years as a general manager across digital and media industries with deep expertise at the intersection of marketing, growth and product. Open, direct, and happiest discussing ideas over great coffee.
LinkedIn