AgentSAT

An internal benchmark that tests whether AI agents are actually ready for your company.

Comment

Inspiration

There is an old saying that half-knowledge is more dangerous than no knowledge at all.

I think the same is becoming true for AI agents.

A weak agent is easy to distrust. But an agent that works correctly 80% or 90% of the time is much more dangerous, because eventually we start trusting it. We give it access to company data, let it write code, generate financial reports, call tools, and make changes on our behalf.

Then one day it confidently picks the wrong dataset, misunderstands an internal business definition, exposes information it should not have accessed, or introduces a subtle bug into production.

Nothing necessarily crashes. The output can look completely reasonable.

That is the problem that interested me.

Companies are moving quickly from experimenting with AI agents to actually using them inside Finance, Engineering, Sales, Operations, and analytics. But before giving an internal agent meaningful access, how do we actually know that it understands this company well enough to trust?

Generic benchmarks can tell us whether a model can reason, code, or use tools. They cannot tell us whether a Finance agent understands your definition of Net Revenue, knows which internal dataset is authoritative, avoids deprecated sources, asks for clarification when company terminology is ambiguous, or follows your internal data policies.

Most teams still rely on a small set of manually written evals, which quickly become stale and are easy for an agent to overfit to.

That led to AgentSAT.

The idea is simple:

Before an AI agent is trusted inside a company, it should have to prove that it understands the company it is about to work for.

What it does

What it does

AgentSAT is an internal testing platform for AI agents.

I connect an agent, describe what it is supposed to do, and optionally add specific risks I want tested. AgentSAT then uses the company’s DataHub context to build a private test suite around the real environment the agent will work in.

For a Finance agent, that can include:

  • understanding company-specific metrics
  • choosing the correct internal datasets
  • avoiding deprecated sources
  • handling ambiguous requests
  • following data access rules
  • completing real analytical tasks correctly
  • responding safely to adversarial cases

The agent is then tested on those scenarios using its real tools and LLM.

AgentSAT records what the agent actually does, including the data it selects, SQL it generates, tools it calls, and final answers.

The result is not just a score.

AgentSAT creates a detailed engineering report showing what failed, why it failed, the evidence behind each finding, how serious the problem is, and what I should fix before deploying the agent.

After the agent is improved, I can submit the new version and run the test again. AgentSAT compares both versions and shows which problems were fixed and what still needs work.

How we built it

How I built it

I built AgentSAT with Next.js, TypeScript, FastAPI, Python, DuckDB, DataHub Core, and Groq.

DataHub provides the company context AgentSAT tests against, including business definitions, schemas, approved and deprecated datasets, governance metadata, and query patterns.

Groq is used for the parts that need language reasoning. It helps interpret custom testing requirements, generate realistic test scenarios, run the demo agent, and turn verified failures into a clear engineering report.

I kept scoring separate from the LLM.

For each test, AgentSAT builds an objective expected result using executable SQL, DataHub metadata, policy rules, or required actions such as asking for clarification or refusing a request. The LLM can generate a scenario, but it cannot decide whether the agent passed.

Generated tests also go through validation before they are used. AgentSAT removes tests that are ambiguous, unverifiable, trivial, or do not have a reliable expected result.

The test suite mixes stable regression tests with fresh hidden variants so an updated agent cannot simply memorize the exact prompts it failed before.

I also built versioned retesting. After a team fixes an agent, I can run the new version against previous failure cases and new variants, then compare both reports to see what actually improved.

Challenges we ran into

Challenges I ran into

The hardest part was making AgentSAT a real evaluation system instead of an LLM testing another LLM.

I needed generated tests to be difficult, but also objectively correct. I solved this by separating test generation from scoring and requiring each important test to have an executable or deterministic answer.

Another challenge was making failures useful. A score alone does not help an engineering team, so I built the report around evidence, root causes, reproduction steps, and specific fixes.

Accomplishments that we're proud of

Accomplishments that I’m proud of

I am most proud that AgentSAT does more than give an agent a score.

It finds specific failure modes, proves them with evidence, groups them into root causes, and turns them into an engineering report that can actually be used to improve the agent.

I am also proud that the tests are dynamic, objectively scored, and can be rerun against a new agent version to measure whether the fixes actually worked.

What I learned

I learned that an agent can look reliable while still failing in dangerous ways. The hardest failures are often not crashes, but confident answers based on the wrong company context.

I also learned that AI is useful for generating and explaining tests, but the final pass or fail needs objective evidence.

What’s next for AgentSAT

Next, I want to test real internal agents beyond the Finance demo and support more domains such as Engineering, Sales, and Operations.

I also want to integrate AgentSAT into CI/CD so every new agent version can be tested automatically before deployment.

Built With

Share this project:

Updates