Someone writes a prompt, connects a few tools, tests a handful of examples, and starts using the result. When something goes wrong, they adjust the prompt and try again.

That can work for a demo.

It does not create a reliable operating system.

I’m approaching agent development differently. I’m treating every agent as a governed decision-making system that needs a contract, a test suite, and a promotion process.

The loop is simple:

Create → test → learn → revise → regress → promote.

The important part is that the loop never depends on hope.

Every agent starts with a contract

Before I create an agent, I define what it is responsible for.

That definition goes beyond a job title or a paragraph describing its personality. The contract needs to establish the boundaries of the agent’s authority.

It should answer questions like:

• What decisions does this agent own?

• What inputs can it trust?

• What evidence must it provide?

• What actions require human approval?

• What conditions should cause it to escalate?

• What must it never do?

• When should it stay silent?

That last question deserves more attention than it gets.

Most agents are implicitly rewarded for producing something. They answer because the system expects an answer, even when the available evidence is weak or the request falls outside their scope.

But silence can be the correct behavior.

An agent that confidently acts beyond its authority is not autonomous. It is uncontrolled.

The written contract becomes the canonical definition of acceptable behavior. It gives me something more durable than a collection of prompt fragments and one-off fixes.

Synthetic scenarios expose the gaps

Once the contract exists, I test the agent against synthetic scenarios.

These aren’t just happy-path examples where the correct response is obvious. The useful scenarios are designed to create tension:

• The available evidence is incomplete.

• Two instructions appear to conflict.

• A seemingly harmless request crosses a safety boundary.

• The agent has enough information to speculate but not enough to decide.

• A user pressures the agent to act outside its authority.

• The technically correct answer would still produce the wrong business outcome.

• The best response is no response at all.

The point is not to trick the agent.

The point is to discover where its contract is ambiguous, incomplete, or too dependent on assumptions that were never written down.

Each failure tells me something about the system.

Sometimes the agent misunderstood its role. Sometimes it did not have a clear escalation path. Sometimes the evidence requirements were too loose. Sometimes the contract rewarded activity when it should have rewarded restraint.

Those are not isolated response problems. They are specification problems.

Correctness is not enough

An agent can arrive at the right answer for the wrong reasons.

That means evaluating only the final output is not enough. I score the behavior across several dimensions:

Decision quality: Did the agent make the appropriate decision given the information available?

Evidence: Did it ground the decision in relevant, verifiable information?

Safety: Did it respect the boundaries of its authority?

Escalation: Did it recognize when human judgment was required?

Restraint: Did it know when not to answer or act?

This creates a much more useful definition of quality.

A polished response with invented evidence should fail. A technically correct recommendation that ignores a safety boundary should fail. An agent that takes action when it should have escalated should fail.

The standard is not whether the output sounds intelligent.

The standard is whether the behavior can be trusted.

Fix the contract, not the example

When a scenario exposes a failure, it is tempting to patch that specific example.

Add another instruction. Insert another exception. Tell the agent not to make that exact mistake again.

That produces brittle systems.

Instead, I ask what was missing from the canonical contract.

Was the agent’s authority unclear? Were the evidence requirements incomplete? Did I fail to define a refusal condition? Was the escalation path ambiguous? Did the scoring system reward the wrong behavior?

I update the contract at the level of the underlying principle.

Then I rerun the entire suite.

This matters because every fix creates the possibility of a regression. A change that solves one scenario can quietly damage behavior somewhere else.

Without regression testing, improvement is difficult to distinguish from movement.

Promotion should be earned

An updated agent does not automatically become the new production version.

It gets promoted only after it passes:

1. The scenario that exposed the original gap

2. The existing regression suite

3. The safety and evidence thresholds defined for its role

This creates a clear separation between experimentation and trusted behavior.

It also produces an audit trail. I can see why the contract changed, what failure prompted the change, and which scenarios the new version passed before promotion.

That history becomes part of the system’s intelligence.

Not because the model itself remembers every failure, but because the operating system does.

The real product is the improvement loop

The individual agent is only one part of what I’m building.

The more valuable asset is the system around it:

• Written behavioral contracts

• Synthetic evaluation scenarios

• Consistent scoring criteria

• Regression testing

• Versioned changes

• Promotion gates

Together, these turn agent development into an engineering discipline.

The goal is not to create an agent that performs brilliantly once.

The goal is to create a system that can fail, reveal why it failed, absorb the lesson, and improve without forgetting what it already learned.

That is the difference between building an AI agent and building an operating system for agents.

One produces outputs.

The other produces increasingly reliable behavior.

Join me as i go live around persona packs, get in the room, take away a few tid bits : https://luma.com/3626zfyr

A user asks a question.
The model produces a polished answer.
The answer sounds intelligent.
Everyone moves on.

That may be enough for a demo. It is not enough for an operating workflow.

When an AI system is helping manage advertising, listings, inventory, catalog issues, pricing, or marketplace performance, a convincing answer can still be wrong in dozens of ways.

It may have:

• Selected the wrong workflow.

• Used the wrong source.

• Compared mismatched date ranges.

• Treated attributed ad revenue as total sales.

• Used stale evidence.

• Missed an important required input.

• Confused correlation with causation.

• Recommended increasing demand on a product approaching a stockout.

• Hidden uncertainty behind confident language.

None of those problems can be detected by asking only, “Does the final answer sound good?”

That is why I believe the right unit of evaluation is the workflow—not the response.

And that idea is becoming a central part of how I am building Helm.

What is an eval?

An evaluation, or “eval,” is a repeatable way to test whether an AI system behaved as intended.

The AI industry often discusses evals in terms of model benchmarks, response grading, or an LLM judging another LLM’s answer. Those techniques can be useful, but they are only one layer.

For an operational system, the more important questions are often:

• Did the system understand what the operator was asking?

• Did it choose the correct workflow?

• Did it identify the information required to run that workflow?

• Did it use the right tools and data sources?

• Was the evidence current and complete enough?

• Did the strength of the recommendation match the strength of the evidence?

• Did it respect the business’s guardrails?

• Was the result useful to the human who had to make the decision?

Those questions cannot be answered by grading prose alone.

Consider a simple Amazon question

Imagine an operator asks:

“Why did sales drop last week?”

A generic assistant could produce a plausible list of causes: traffic, conversion, price, inventory, advertising, competition, or seasonality.

That answer might read well while doing almost no useful work.

A real sales-drop workflow must determine:

1. Which account, brand, SKU, or ASIN is in scope?

2. What does “last week” mean, and what comparison period should be used?

3. Did traffic decline, conversion decline, or both?

4. Did Buy Box ownership, price, availability, or listing content change?

5. Did advertising delivery change?

6. Are the sources current and measuring comparable windows?

7. Which causes are supported by evidence?

8. Which explanations remain plausible but unverified?

9. What action is safe to recommend?

10. What evidence would most improve the next run?

This is not one prompt. It is an operating procedure.

If we want dependable AI systems, that procedure has to become evaluable.

How Helm approaches workflow evaluation

Helm is the operating layer I am building for Amazon brands, agencies, and operators. It connects business questions to bounded workflows, routes the required evidence, applies brand context and guardrails, and returns review-ready recommendations.

The evaluation architecture follows the same path as the workflow itself.

1. Routing evaluation

Before Helm can answer a question, it must select the correct workflow.

“Where am I wasting ad spend?” should route to an ad-waste audit.

“Traffic is stable, but conversion dropped” should route toward a listing-conversion diagnosis.

“Why is this competitor beating us?” should trigger a competitive-positioning workflow.

Helm uses a registry of defined workflows and tests representative operator questions against expected routes. These become regression cases: when the routing logic changes, the same questions can be rerun to see whether something improved or broke.

This catches a class of failure that a final-answer grader may never see. A model can produce a polished response after choosing the wrong analytical path.

2. Input-readiness evaluation

Each workflow has required and optional inputs.

If a keyword-gap workflow requires niche context, Helm should not quietly pretend it has that context. If a promotion post-mortem needs the promotion window, it should ask for it.

The evaluation is not simply, “Did the system answer?”

Did the system know when it had enough information to proceed?

Asking for unnecessary information is also a failure. A useful system should distinguish between inputs that are truly required and inputs that would merely improve confidence.

3. Evidence-contract evaluation

Different questions require different evidence.

An ads-performance packet should include spend, attributed sales, efficiency metrics, and campaign- or search-term-level detail.

A sales-performance packet should include the reporting period, account or marketplace scope, sales totals, and source freshness.

A catalog-quality packet needs the affected SKU or ASIN, the issue, its severity, and the recommended next step.

Helm defines these expectations as evidence contracts.

External evidence can then be assessed across dimensions such as:

• Freshness

• Completeness

• Source confidence

• Fit for the requested workflow

This matters because “data was returned” is not the same as “the workflow received the evidence it needed.”

4. Source and execution evaluation

Helm also tracks what happened during the run:

• Which workflow was selected?

• Was it ready to execute?

• Which tools were planned?

• Which tool actually ran?

• Which sources succeeded?

• Which sources failed or were unavailable?

• Was cached evidence used?

• How long did execution take?

• Was the result complete, partial, or blocked?

This makes failures diagnosable.

Instead of “the AI gave a bad answer,” we can identify a more useful failure:

• Wrong workflow

• Missing input not detected

• Wrong first tool

• Source not configured

• Weak evidence

• Incorrect date window

• Unsafe recommendation

• Unsupported claim

• Tool failure

• Result not actionable

That classification is what turns isolated mistakes into an improvement system.

5. Confidence and safety evaluation

Confidence should be an output of the evidence, not a personality trait of the model.

Helm’s workflows define what must be included, what must be avoided, known failure modes, and the decision rules that apply.

For example:

• Do not calculate definitive days of cover without actual inventory and inbound data.

• Do not recommend more advertising for a near-stockout ASIN.

• Do not treat BSR movement as a root cause.

• Do not invent Amazon policy language.

• Do not submit catalog, pricing, listing, or advertising changes without the appropriate human review.

When evidence is incomplete, Helm is designed to continue with a bounded partial read, lower the confidence, and name the missing evidence.

The goal is not artificial certainty. It is calibrated usefulness.

6. The run receipt

Each Helm investigation can produce a run receipt summarizing:

• The selected workflow

• Workflow-match strength

• Execution status

• Sources used

• Sources missing or skipped

• Evidence coverage

• Confidence limits

• What capped confidence

• The next best input

The receipt is not intended to be a magical judge that proves every sentence is correct.

It is a compact record of how the answer was produced and where its limits are.

That distinction matters. Transparency is not the same as truth, but it makes truth easier to inspect.

7. Human and business-outcome evaluation

Ultimately, an operational workflow has to be useful to an operator.

Helm captures feedback signals such as:

• Useful result

• False positive

• Weak evidence

• Missing source

• Routing miss

• Unsafe or unactionable recommendation

• Time saved

• The next workflow the operator needs

Those signals can be aggregated into workflow scorecards showing routing performance, execution success, recurring source gaps, failure types, alert usefulness, and operator feedback.

This is where evals stop being a technical benchmark and start becoming an operating feedback loop.

Evals should create organizational memory

The most valuable result of an eval is not a score.

It is memory.

A good evaluation system helps a team remember:

• What a successful workflow looks like.

• Which evidence is required.

• Which mistakes have happened before.

• Which recommendations operators consistently edit or reject.

• Where a source is unreliable or incomplete.

• Which guardrails protect the business.

• Whether a change improved the system or reintroduced an old failure.

Without this structure, every AI mistake becomes an anecdote.

Someone says, “That answer wasn’t very good,” a prompt gets edited, and nobody knows whether the change helped the rest of the system.

With structured evals, the loop becomes:

Run → inspect → classify → improve → regression test → run again

That is how an AI workflow becomes dependable over time.

What Helm does—and does not—claim

Helm does not eliminate human judgment.

It does not guarantee that every recommendation is correct. It does not treat a numeric score as proof of truth. And its run receipt is not currently a final-answer prose grader.

Instead, Helm makes the operating chain visible and testable:

• The question

• The selected workflow

• The required inputs

• The tools and sources

• The evidence standard

• The confidence limits

• The guardrails

• The human response

• The business outcome

That is a much stronger foundation than evaluating whether an answer merely sounds intelligent.

The question every AI workflow needs to answer

If your agent makes the same kind of decision 100 times, can you explain why run 37 failed?

Was it the prompt?
The routing?
The source?
The date window?
The evidence?
The guardrail?
The model?
Or the workflow itself?

If you cannot answer that question, you do not yet have an AI operating system.

You have a collection of outputs.

Helm is being built around the idea that access to tools is only the beginning. The real work is defining how those tools should be used, what evidence is good enough, when confidence should be limited, what humans should review, and how the system improves from every run.

MCPs give agents access.
Evals help make them accountable.
Helm gives the entire workflow an operating structure.

If you are building AI into an Amazon brand or agency workflow, I would be interested in hearing what you are trying to evaluate—and which failures are currently hardest to see.

Learn more about Helm

That number matters less than what it represents.

It means Helm is moving away from being an idea about agents and toward something more concrete:

a workflow library for Amazon operations.

I keep saying this, but it is the important distinction:

Amazon teams do not need another dashboard.

They need a system that knows what work needs to happen, what sources to check, what context matters, what output is useful, and when a human needs to review.

That is not a dashboard. That is a workflow.

Why Workflows Matter More Than Tools

Read more

Amazon catalog work is buried inside files that are hard for humans to review and hard for agents to reason over.

Category Listing Reports are full of useful truth. They are also ugly.

If you have operated inside Amazon long enough, you know the feeling:

Read more

Starting July 27, 2026, Amazon says product titles in non-media categories should be 75 characters or less, including spaces. It also describes item highlights as an additional 125 searchable characters for supporting detail.

On paper, that sounds like a title-length rule.

In practice, it is an operations problem.

Because the actual work is not:

“Make the title shorter.”

The actual work is:

“Shorten the title without losing the terms that matter, without guessing, and without letting an AI rewrite push bad changes into Seller Central.”

That is a workflow problem.

So I made a public repo for it ( also just shipped some updates today) :

Helm Amazon Title Workflow

It is a free Helm workflow example for Amazon operators preparing for the 75-character title change.

Why This Is Not Just Copywriting

A title rewrite is deceptively easy to get wrong.

You can shorten a title and still damage the listing.

You can keep it readable and accidentally remove the strongest keyword.

You can preserve keywords and make the title sound like a pile of search terms.

You can use AI to generate a cleaner version and still have no idea whether it preserved the right terms.

That is why I do not think this should be treated as a prompt-only problem.

It needs a workflow.

The Workflow

The public workflow is intentionally simple. It gives operators a practical sequence:

1. Audit a Category Listing Report with Catalog CLI.

2. Identify titles that need rewrite review.

3. Preserve the strongest existing title terms.

4. Pull keyword or search-volume evidence from tools like DataDive, Helium 10, or another MCP.

5. Draft shorter title candidates and item highlights.

6. Require human review before anything changes in Seller Central or Vendor Central.

That last step matters.

This repo does not publish changes. It does not submit feed updates. It does not approve Amazon AI recommendations. It produces review-ready recommendations for an operator to accept, edit, or reject.

That is the right shape for this kind of work.

Where Catalog CLI Fits

Catalog CLI is the first evidence layer.

Instead of starting with a blank prompt, you start by auditing the actual catalog file.

For this title workflow, the important check is:

catalog check mobile-title-readiness /path/to/catalog.xlsx --format json

Or through MCP:

catalog_check(query=”mobile-title-readiness”, file=”/path/to/catalog.xlsx”)

The goal is not just to say “this title is too long.” The goal is to prepare the title for review:

• current title

• character count

• first 75-character visible segment

• overflow text

• significant terms

• item highlight status

• recommended next action

That gives an AI agent or human operator something much better than vibes. It gives them structured evidence.

The Missing Piece Is Keyword Evidence

The title itself does not tell you which terms matter.

That is where a keyword source comes in. It could be DataDive. It could be Helium 10. It could be another MCP. It could be a spreadsheet if that is what the team has.

The important thing is that the rewrite should not blindly preserve every term. It should preserve the terms that have evidence behind them.

That is the difference between:

“Make this title shorter.”

and:

“Make this title shorter while protecting the strongest evidence-backed terms.”

That is a much better task for an agent.

Why This Is a Helm Example

This repo is public and intentionally lightweight.

It is not the private Helm harness. It does not include hosted orchestration, memory, monitoring, source credentials, writeback, billing, or customer-specific rules.

But it does show the pattern.

Helm is not just about connecting tools. It is about turning messy Amazon work into workflows:

• define the trigger

• pull the right evidence

• preserve the business context

• route across sources

• produce a review-ready output

• keep a human in the loop

• learn from what gets approved or rejected

The title change is simply a timely example.

This Is the Pattern I Keep Coming Back To

Amazon operators do not need more disconnected alerts.

They need practical workflows that help answer:

• What changed?

• Why does it matter?

• What evidence supports the recommendation?

• What should be reviewed before action?

• What should be remembered next time?

That is why this title-change workflow matters to me.

It is not just a title workflow. It is a small example of the operating layer I think Amazon teams are going to need.

One policy change. One catalog file. One workflow. Human review before action.

That is the shape.

Try It

The repo is here:

BWB03/helm-amazon-title-workflow

If you already have Catalog CLI installed, start with:

catalog check mobile-title-readiness /path/to/catalog.xlsx --format json

Then use the workflow, prompt, schema, and examples in the repo to move from audit to review-ready title candidates.

If you want the bigger operating layer around this kind of work, that is what I am building with Helm.

The goal is not to make AI rewrite titles. The goal is to make sure the workflow preserves the right context before anything changes.

The public repo shows the workflow. Helm is where that pattern becomes an operating system across the rest of the catalog work.

Every Amazon seller experimenting with AI agents hits the same wall, usually without knowing it: context tax.

When you connect an MCP server (the standard way AI assistants like Claude talk to external tools) to your AI, every single tool that server exposes gets loaded into the AI’s context window — before you type a word. The tool’s name, its description, its full parameter schema. Every conversation. Every time.

Connect three data sources — say Keepa for pricing history, SmartScout for market intelligence, and DataDive for keyword research — and you’re paying that tax three times over.

We measured it.

That’s roughly a 70% reduction in fixed context overhead — before the conversation even starts.

(Methodology note for the skeptics: we sampled real tool definitions from each server and estimated tokens at ~4 characters per token. SmartScout’s schemas are notably verbose — its product search tool alone is ~350 tokens. These aren’t synthetic benchmarks; they’re the actual schemas these servers ship.)

And our numbers are conservative compared to what others have found. An open issue on the MCP specification itself documents heavy tools costing ~1,000 tokens each to define. Anthropic’s own engineering team reported agent setups where tool definitions consumed 134,000+ tokens before optimization, and a “modest” five-server setup eating ~55,000 tokens before the first message.

The bigger win: what happens per question

Schema overhead is the visible tax. The invisible one is worse.

Ask a raw multi-MCP setup “how is my product doing?” and here’s what actually happens:

1. The AI calls Keepa for product data → 2,000–5,000 tokens of raw JSON come back

2. It calls SmartScout for market context → another few thousand tokens

3. It calls DataDive for keyword ranks → another few thousand

4. All of that raw payload sits in context while the AI stitches an answer together

One question: 10,000–20,000 tokens of intermediate data, most of which the AI reads once and never needs again — but which stays in the context window for the rest of the session, degrading quality and inflating cost.

Helm inverts this. A single aggregated call — business_overview — does the multi-source fetch server-side, synthesizes the signals, and returns one shaped response. The AI sees the answer, not the plumbing.

This is exactly the pattern Anthropic now recommends. Their engineering post on efficient agents describes cutting a workflow from 150,000 tokens to 2,000 tokens — a 98.7% reduction — by moving data aggregation out of the model’s context and returning only synthesized results. Anthropic’s Tool Search feature exists for the same reason and claims an 85% reduction in tool-definition context.

Helm bakes that architecture in. You don’t configure it; it’s just how the connector works.

What it adds up to

For a typical working session — five or six real questions about your business — the difference between three raw MCPs and Helm is roughly 30,000–50,000 tokens saved. Every session. Every user.

That translates directly to:

• Lower cost — fewer tokens processed per conversation

• Faster responses — less context to read means lower latency

• Better answers — models measurably degrade as context fills with noise; a lean context is a sharper analyst

• More headroom — tokens not spent on schemas and raw JSON are tokens available for actual analysis, longer sessions, and bigger documents

The takeaway

Connecting AI to your Amazon data isn’t just about access — every tool ever built for MCP gives you access. It’s about what that access costs on every single message.

Three separate connectors means paying schema tax three times and hauling raw API payloads through the model on every question. One curated, aggregating connector means the model spends its context on your business instead of your plumbing.

That’s the bet behind Helm.

Sources

• Anthropic Engineering — Code execution with MCP: building more efficient AI agents (150K → 2K token workflow reduction; intermediate-result overhead)

• Anthropic Engineering — Introducing advanced tool use on the Claude Developer Platform (Tool Search Tool, 85% context reduction)

• MCP Specification, GitHub Issue #2808 — Tool schema token overhead (~1,000 tokens/tool)

• DeployStack — How MCP servers use your context window (per-tool token breakdown)

• Primary measurement: live Claude session, July 2026 — actual tool schemas sampled from Keepa (18 tools), SmartScout (13), DataDive (13), and Helm connectors; tokens estimated at ~4 chars/token

They start with:

What tool can the agent call?

That is useful, but it is not the starting point.

The better starting point is:

What workflow do I repeat often enough that it deserves a system?

Once you know the workflow, the tools become clearer.

This is the template I keep coming back to when I turn Amazon work into agent workflows.

The Template

Every agent workflow needs eight parts:

1. Trigger

2. Context

3. Sources

4. Evidence contract

5. Routing rules

6. Output format

7. Review state

8. Feedback loop

If one of those is missing, the workflow usually becomes fragile.

It may still work once.

But it will be harder to trust, harder to debug, and harder to improve.

Read more

Summary

An automated, read-only advertising-monitoring agent produced its daily brief and flagged a top-priority “campaign setup error” across a whole family of campaigns. On review, the operator’s instinct said something was off. A two-minute follow-up confirmed the agent had drawn the right data but the wrong conclusion. The finding was corrected, the saved report and its structured data were updated, and a durable note was added so the agent won’t repeat the mistake.

Net impact: no wrong action was taken (the agent is recommend-only), and the error was caught before it influenced any decision.

What the agent reported

The agent flagged that an entire family of “cross-target” campaigns was targeting their own advertised product — i.e. self-targeting — and raised it as the #1 priority, implying a systemic setup bug to unwind.

What was actually true

The campaigns were set up in a legitimate but opposite direction from what the agent assumed:

• The agent assumed the product being advertised matched the product named in the campaign title (the “hub”).

• In reality, the campaigns advertised the secondary products (”spokes”) and used the hub product only as the target — so the secondary products’ ads appeared on the hub’s high-traffic page.

• Advertised product and targeted product were therefore different items. No campaign was targeting its own advertised product. It was not self-targeting at all.

One of these campaigns was actually performing well; one was simply inefficient. “Inefficient” is a performance note, not a structural defect.

Root cause

The agent inferred a key attribute (the advertised product) from a proxy (the campaign’s name) instead of pulling it from the source field. The data it retrieved was correct; the interpretation layer over-trusted a naming convention. Because the conclusion was stated with high confidence and ranked #1, it looked authoritative.

How it was caught

The operator read the finding against their own mental model of how they’d built the campaigns and asked a clarifying question — essentially, “Wait, did I set this up the other way around?” That question, not a system alert, is what surfaced the error. The operator’s domain intuition was the real detector.

How it was corrected

1. Verified from the source, not the proxy. Pulled the advertised product field and the targeted product field separately and compared them. They differed — disproving the self-target claim and revealing the true direction.

2. Fixed the deliverables. Removed the incorrect top-priority finding, re-ranked the remaining items, and reframed the one genuinely weak campaign as an efficiency issue rather than a setup issue. Updated both the human-readable report and the machine-readable data file, and re-synced the “latest” pointer.

3. Prevented recurrence. Added a persistent note to the agent’s memory: never infer the advertised product from a campaign name; always confirm self-targeting by comparing the advertised-product field against the targeted-product field, and only flag it when the same item appears as both.

Why it worked out well

• The agent was recommend-only. It surfaces findings for human review and cannot change anything on its own, so a wrong conclusion could not become a wrong action.

• The output was specific and evidence-backed. Because each finding carried its underlying numbers and identifiers, the claim was cheap to audit and disprove.

• The human stayed in the loop. The operator treated a confident AI conclusion as a hypothesis to test, not a fact to accept.

• The fix was systemic. The correction didn’t stop at this one report; it changed how the agent will interpret this pattern in every future run.

Takeaways

• Confidence is not correctness. Rank and certainty in an AI report should invite scrutiny on high-impact items, not replace it.

• Distinguish “the data is wrong” from “the interpretation is wrong.” Here the data was right; the inference was not. They have different fixes.

• Pull attributes from source fields, not from names or labels that merely imply them.

• Domain experts are the best detectors of subtle model errors — design the workflow so their instinct has an easy path to challenge a finding.

• When you correct an agent, correct the deliverable and the behavior, so the lesson persists.

The Model Is Not the Moat. The Loop Is the Moat.

Satya Nadella posted something this weekend that seemed to hit a nerve.

The short version: AI is not just another software shift. If companies are not careful, they risk giving up the thing that makes them valuable in the first place: how they learn.

The Business Insider summary framed it around a concern that a few AI providers could absorb too much corporate knowledge and capture too much of the value. Satya’s point, as I read it, was not anti-AI. It was more specific than that.

Companies need to own their own learning systems.

That language can sound abstract, especially when people start talking about human capital, token capital, frontier ecosystems, and all the other words that tend to pile up around AI.

But the underlying idea is simple:

If every company uses the same models, the advantage is not the model. The advantage is the loop around the model.

That is the part I have not been able to stop thinking about.

And it is exactly why I have been so obsessed with Helm.

Amazon Teams Do Not Have a Data Problem

If you have ever actually operated an Amazon account, you know the problem is not:

“We need more data.”

We have data everywhere.

Seller Central.

Keepa.

Ad reports.

Catalog tools.

Brand Analytics.

Spreadsheets.

Slack threads.

Client calls.

Notes from six months ago that somehow still matter.

The real problem is that none of it thinks together.

None of it remembers the brand strategy.

None of it knows why you made the last decision.

None of it connects the Buy Box issue to the ad performance issue to the catalog issue to the client’s actual goal.

A sales drop might be ads.

It might be Buy Box.

It might be price.

It might be inventory.

It might be listing content.

It might be catalog.

It might be reviews.

It might be rank.

It might be a competitor move.

And if you have been doing this long enough, you know the answer is often “three of those things at once.”

That is why Amazon work is hard to automate cleanly.

The data is fragmented, but the judgment is connected.

The Dashboard Is Not the Loop

A dashboard can show you what happened.

That is useful.

But a dashboard usually does not know what you were trying to do.

It does not know the margin structure.

It does not know the client said last quarter, “We are willing to protect rank here, but not at the cost of margin.”

It does not know that a listing change is fine for one brand and a problem for another.

It does not know that the operator already investigated this issue two weeks ago and decided to watch it.

It does not know that the same pattern keeps showing up every Monday after inventory sync.

That is the gap.

A dashboard shows what happened.

A learning loop helps the team get better every time it happens.

For Amazon teams, the loop looks something like this:

Brand context -> marketplace signals -> data calls -> operator judgment -> recommendation -> action -> outcome -> memory -> better future decisions.

That is different from “chat with your data.”

Chat with your data is one interaction.

A loop remembers.

This Is Where Helm Fits

This is the gap Helm is trying to close.

Yes, the first workflow is monitoring listings and marketplace changes.

But that is just the first place the loop becomes obvious.

The listing monitor is the first workflow.

The learning loop is the company.

The bigger vision is to build an operating layer for Amazon teams where brand context, strategy, tools, data sources, and operator judgment all work together.

So when something changes, Helm does not just say:

“Here is a metric.”

It should be able to say:

“Here is what changed, here is why it matters for this brand, here is the likely cause, and here is what I would look at next.”

That is the loop.

And I think that loop becomes the real IP for Amazon agencies, consultants, and brands.

The model is not the moat.

The loop is the moat.

MCPs Are the Pipes

MCPs and connected data sources matter.

They matter a lot.

They let a system like Helm pull from the right places at the right time: marketplace data, catalog data, ads data, keyword data, internal docs, past decisions, and brand-specific context.

But the pipe is not the value by itself.

If all you have is a pipe into another dashboard, you still have the same problem.

The real value is the operating loop around the work.

What source should be checked first?

What does good evidence look like?

What should be ignored?

What should be escalated?

What does this brand care about?

What happened last time?

What did the operator decide?

Did the recommendation work?

That is where the learning happens.

MCPs are the pipes.

Helm is being built around the operating loop.

Operator Judgment Is the Asset

I do not think AI makes Amazon operators less important.

I think it makes the best operators more important.

The good operators already have pattern recognition that no generic model automatically has.

They know when a metric is noisy.

They know when a client is asking the wrong question.

They know when a catalog issue is urgent and when it is just ugly.

They know when an ad problem is really a listing problem.

They know when the answer is “do nothing for 48 hours and watch.”

That judgment is the asset.

The problem is that most of it lives in people’s heads, Slack messages, old spreadsheets, call notes, and scattered docs.

So when a person leaves, the judgment walks out with them.

When an agency grows, the judgment gets uneven across account managers.

When a brand changes teams, the context gets reset.

When things get busy, people fall back to dashboards and checklists because there is no shared memory around how decisions get made.

That is what I think the AI shift changes.

Not because AI magically replaces the operator.

Because AI gives teams a chance to encode how they think.

The Agency of the Future

The agency of the future will not just manage accounts.

It will encode how it thinks.

That does not mean every decision becomes automated.

It means the repeatable parts of diagnosis become clearer.

It means every review, miss, exception, and client-specific rule can make the next run better.

It means a senior operator’s judgment can start to scale across more accounts without pretending every account is the same.

It means a brand can build institutional memory instead of constantly rebuilding context.

It means the question shifts from:

“Which AI model are you using?”

to:

“Does your business own the loop around how decisions get made?”

That is a much better question.

Because generic AI can summarize a report.

It does not automatically know the brand, the strategy, the margin structure, the prior decision, or the client context.

Those are the things that make the answer useful.

The First Workflow

The first Helm workflow is listing and marketplace monitoring because that is where the pain is obvious.

Listings change.

Prices move.

Buy Box status shifts.

Seller count changes.

Rank moves.

Ads performance gets blamed.

Catalog issues hide underneath everything.

Client questions come in before anyone has checked all the sources.

That is a perfect place to build the first loop.

Not because listing monitoring is the whole company.

Because it is the doorway.

Once you can connect brand context, marketplace signals, catalog history, prior decisions, and operator review around one workflow, you can start to extend the same pattern into ads, catalog, keyword gaps, competitive movement, client reporting, and account strategy.

That is where Helm is going.

The Moat

I do not think the future of Amazon operations is one magic AI tool.

I think it is owned learning loops around the work.

Every brand, agency, and marketplace team should be able to build systems that understand their context, remember their decisions, and help their operators get better over time.

That is the stable version of this AI shift.

And that is what I am building toward with Helm.

The model is not the moat.

The loop is the moat.

Here is a link to the article in mention:

One of the first packaged Helm workflows I keep coming back to is Listing Guard.

The reason is simple: Amazon listing problems rarely show up in one clean place.

A Buy Box issue might look like a pricing problem, but it could be a reseller problem.

A sales drop might look like an ads issue, but it could be caused by an out-of-stock risk, a listing content change, a bad catalog attribute, a suppressed variation, or a competitor move.

A listing might look “fine” in Seller Central, but the catalog file tells a different story.

This is why I do not think the future is just “chat with your dashboard.”

The useful version is:

Ask one operational question, route it across the right sources, capture the evidence, classify the issue, and produce the next action.

That is the Listing Guard workflow.

Read more

Based on the announcement sellers have started receiving, product titles in most categories will need to be 75 characters or less, including spaces, starting July 27, 2026. Amazon is also introducing item highlights: an additional 125 searchable characters that can carry supporting details that no longer fit in the title.

If you work on Amazon listings, you can probably feel the operational headache already.

Some brands have a few dozen titles to review. Agencies and operators may have hundreds or thousands. A lot of existing titles were written for an older Amazon reality: long, keyword-stuffed, full of product details, compatibility language, material callouts, use cases, and every phrase someone thought might help indexing.

Now the question becomes:

What deserves to stay in the first 75 characters?

And just as importantly:

What should move somewhere else?

The Risk

This is the kind of platform change that creates a gold rush.

Every tool, consultant, prompt pack, and AI wrapper is going to promise to “fix your titles.” Some of that will be useful. Some of it will be rushed. Some of it will probably rewrite titles in a way that technically fits the new limit but quietly drops the terms that were doing the most work.

That is the part I care about.

This should not just be a shortening exercise.

The goal is not to make a title fit 75 characters. The goal is to preserve the best product identity and keyword intent inside 75 characters, then move the right supporting details into item highlights or another appropriate field.

That requires evidence. It requires judgment. And it should require human review before anything gets pushed back into Seller Central or Vendor Central.

What We Built

I added a new check to Catalog CLI called:

mobile-title-readiness

It is also available through the aliases:

title-75
amazon-title-75

Catalog CLI already audits Amazon Category Listing Reports. This new check looks through your CLR and flags any listing where the title is over 75 characters.

But it does more than say “too long.”

For each over-limit title, it returns rewrite-ready context:

• current title character count

• how many characters over the limit it is

• the first 75 characters

• the overflow text after character 75

• significant terms in the priority zone

• significant terms in the overflow zone

• all significant terms from the original title

• whether item highlights appear to be present

• item highlight character count when available

• a recommended next action

The point is simple: give an operator or agent the raw material needed to make a better decision.

Example:

catalog check mobile-title-readiness my-catalog.xlsx --format json

Or through the Catalog CLI MCP:

catalog_check(query="mobile-title-readiness", file="/path/to/catalog.xlsx")

This works in the CLI, MCP server, JSON output, field masks, pagination, and the hosted Catalog CLI Pro API.

Why This Is Open

I do not want this to become another black-box “AI optimization” moment.

The rewrite process should be inspectable. Operators should be able to see which original terms were kept, which were dropped, and why. If a term has search volume, relevance, conversion history, or brand importance, that should be part of the decision.

So alongside the Catalog CLI check, we created a separate public workflow repo:

https://github.com/BWB03/helm-amazon-title-workflow

The repo is intentionally lightweight. It is not a private platform dump. It is a community workflow people can copy, critique, adapt, and improve.

It includes:

• a step-by-step Amazon title 75-character workflow

• a prompt for title rewriting using Catalog CLI output

• a schema for structured rewrite recommendations

• sample Catalog CLI output

• a sample rewrite result

The intended flow is:

1. Upload or point an agent to your CLR.

2. Run the Catalog CLI mobile-title-readiness check.

3. Extract the original title terms.

4. Send those terms to whatever keyword/search-volume source you trust.

5. Compare the original title against candidate rewrites.

6. Score the rewrite.

7. Require human review before anything is updated.

The Workflow We Want

The core idea is that the old title still contains signal.

A good rewrite should not start from a blank page. It should start by asking:

• Which terms are already in the title?

• Which ones appear in the first 75 characters?

• Which ones fall into the overflow?

• Which terms have search volume?

• Which terms are essential to product identity?

• Which terms are risky from a compliance standpoint?

• Which terms belong in item highlights instead of the title?

Then the rewrite can be scored.

The open workflow currently suggests this weighting:

• 40% retained weighted keyword value

• 25% compliance fit

• 20% readability and shopper intent

• 15% risk flags, such as missing brand, unclear product type, or compliance-sensitive claims

That scoring model is not sacred. It is a starting point.

If you work in supplements, apparel, beauty, electronics, grocery, or any category where the tradeoffs are different, I want your feedback. Different categories may need different weighting, different term handling, and different compliance guardrails.

What This Is Not

This is not an auto-publisher.

It does not submit feed updates.

It does not approve Amazon AI recommendations.

It does not replace a content lead, compliance reviewer, or operator who understands the product.

The first version is deliberately a review workflow.

That matters because title changes can affect indexing, conversion, brand consistency, and compliance risk. An AI assistant can help organize the decision, but the operator should still make the decision.

Why Catalog CLI Fits This

Catalog CLI was built to be agent-native.

That means it is not just a terminal tool for humans. It is also designed to be called by AI agents through structured input/output and MCP. A good agent workflow needs reliable primitives. It needs tools that return consistent, inspectable data.

This new title check is one of those primitives.

It does the deterministic audit work locally:

• read the CLR

• find titles over the threshold

• split the title into mobile-visible and overflow sections

• extract significant terms

• return structured data

Then an agent, analyst, or operator can layer judgment and keyword evidence on top.

That separation feels important.

Catalog CLI should not pretend to know search volume unless it has that data. A keyword MCP or external tool should provide keyword evidence. The operator should provide brand and compliance context. The workflow should combine those sources transparently.

Help Make It Better

This is a first pass, not a finished standard.

I would love feedback from:

• Amazon agencies handling bulk catalog rewrites

• brand owners trying to protect organic visibility

• content teams managing compliance-sensitive categories

• keyword tool builders

• MCP builders

• operators who have already received the Amazon notice

• anyone who has strong opinions about title structure

Useful questions:

• What should the confidence score include?

• Which terms should never be dropped automatically?

• How should brand names be protected?

• Should item highlights be generated from overflow terms, keyword evidence, or both?

• How should category-specific compliance rules plug in?

• What does a good before/after review table need to show?

• What data sources should this workflow support first?

If this helps, use it.

If it is missing something, open an issue.

If you have a better scoring model, contribute it.

If you are building Amazon MCPs or keyword workflows, plug into it.

The goal is not for one company to own the answer. The goal is to give the Amazon operator community a transparent workflow that gets better as more people use it.

Catalog changes are coming. The rewrite work is real.

Let’s make the process more inspectable, less extractive, and more useful for everyone.

Links:

• Catalog CLI: https://github.com/BWB03/amazon-catalog-cli

• Open workflow repo: https://github.com/BWB03/helm-amazon-title-workflow

When I started writing under the name Agentic Field Notes, it felt a little early.

There was a lot of talk about agents, but most of it still lived in demo land. Agents could write, summarize, call a tool, maybe move through a browser. Interesting, yes. Useful, sometimes. Operationally trustworthy, not really.

Over the last stretch, the title has started to feel less like a prediction and more like the actual place I spend my days.

I have not been working on one clean thing. I have been building the layer between “AI can do a task” and “AI can be trusted as part of an operating system.” That layer is not flashy. It is queues, task cards, audit trails, source registries, review states, handoff packets, daily notes, and enough friction that the system does not accidentally run away from you.

That sounds boring until it works.

And then it starts to feel like the real thing.

The Core Realization

The biggest shift in my thinking is this:

Everyone is going to have tools. Everyone is going to have MCP servers, connectors, automations, agents, and internal workflows.

The scarce thing will not be access to tools.

The scarce thing will be knowing what to do with them, how to connect them, how to trust them, how to review them, and how to keep the whole system from turning into another pile of tabs.

That has become the center of Helm.

The positioning is still simple: help brands and agencies create agents around the tools they already use, then fill in the gaps where those tools do not exist yet. But the infrastructure underneath that idea has become much more serious.

I do not think the future is one super-agent magically doing everything. I think it looks more like a coordinated field of small specialized systems:

• one tool knows the catalog

• one tool knows ads

• one tool knows Keepa or marketplace signals

• one tool knows customer context

• one tool knows the brand’s operating rules

• one layer knows how to ask for evidence, score it, and route it back into a decision

The hard part is not getting one of those systems to respond. The hard part is making the response usable.

The Helm loop: tools and data are only half the system. The operating layer is what turns them into execution.

What Helm Has Become

A lot of my recent work has been turning Helm from an idea into actual orchestration infrastructure.

The earliest version was about creating workflows and agents for Amazon operators. The newer version is becoming a system for coordinating external evidence.

That means Helm can ask:

• What evidence do we need?

• Which external source might provide it?

• What does “good evidence” look like?

• How fresh does it need to be?

• What workflow does it support?

• Did the answer match what we asked for?

• Should a human review this?

• Should it become part of future recommendations?

Recently I built this out brick by brick.

First came the external MCP source registry. Instead of treating every source as a generic string, Helm now has a read-only registry for sources like catalog tooling, Keepa-style data, ads systems, competitive intelligence tools, and custom MCPs. Each source can carry capabilities, preferred workflows, transport/auth style, freshness expectations, confidence defaults, and status.

Then came the evidence contract registry. This made “good evidence” inspectable. For workflows like ads performance, keyword gaps, competitive keywords, catalog quality, listing quality, customer value, and external evidence, Helm can define required fields, optional fields, freshness expectations, scoring weights, and examples of acceptable evidence.

Then came dispatch planning. Helm can generate a plan that says: for this evidence request, this is the source, this is the capability, this is the suggested tool, these are the args, this is the evidence contract, this is the timeout, and this is how the result should come back.

Then came the dispatch queue. Plans are no longer ephemeral. They can be persisted, tracked, linked to requests, linked to submitted evidence, and observed across statuses like planned, waiting, submitted, expired, weak, missing, or failed.

Then came handoff packets. This is one of the pieces I like most because it turns infrastructure into something another human or agent can actually use. A handoff packet can say: here is the operator-ready instruction, here is the suggested external MCP call, here is the expected payload, here is how to submit the result back.

Then came reconciliation. When evidence comes back, Helm does not just accept it blindly. It can compare the submitted evidence against the original queue item and handoff. Did the source match? Did the capability match? Did the tool name match? Were the required identifiers present? Was the evidence fresh enough? Did it satisfy the contract?

That is the difference between “an agent returned something” and “the system knows whether the thing returned was the thing requested.”

The current state is still intentionally read-only around external calls. That is by design. Before Helm directly calls outside MCPs, it needs policy, allowlists, dry-runs, and audit trails.

So the next layer has been execution readiness:

• an execution policy that decides whether a queued item is eligible for direct external MCP execution

• a secure tunnel adapter scaffold that defines request/response envelopes, timeout handling, error taxonomy, and audit metadata

• a dry-run tool that shows exactly what Helm would call without calling it

• an allowlist that constrains which sources, workflows, capabilities, transports, and scopes are allowed for pilot execution

This is the less glamorous work of making agents safe enough to use.

But I think this is where the real product is.

What It Has Given Me Back

The practical result so far is not abstract.

I did a rough count across my AI work sessions and automations, and the number that came back was about 150 hours saved across 142 sessions. Around 98 of those were autopilot-style runs: daily monitoring, recurring checks, vault updates, report reviews, and small operational passes that would be easy to skip if I had to do them manually.

A rough cut of what the system has already given back: about 150 hours across 142 AI work sessions.

The surprising part is that the biggest lever was not the big build sessions.

It was the boring recurring work.

Daily monitoring. Weekly reports. Small check-ins. The kind of work that compounds quietly because it runs even when I am busy, tired, on calls, or focused somewhere else.

That has changed how I think about AI leverage. The point is not only “can this agent do a hard thing once?” It is also “can this system reliably do the useful little things I would otherwise forget?”

Catalog CLI Pro Became a Real Connector

The other major thread has been Catalog CLI Pro.

This started as a catalog auditing tool. It checks Amazon listing files for missing attributes, required fields, product type mismatches, listing quality problems, bullet coverage, variation issues, duplicate rows, and other catalog problems that are easy to miss when you are buried in spreadsheets.

But the work recently has been about making it usable through ChatGPT and Codex as a real connector.

That required a different kind of polish.

The tool had to work as an MCP surface. It had to expose the right tools. It had to support OAuth and reviewer flows. It had to explain itself clearly enough that a model could choose the right check, run the right scan, and summarize the result without hallucinating or flattening important caveats.

One live test was encouraging: ChatGPT used Catalog CLI Pro to audit a real catalog, ranked the top issue areas, gave counts, explained why they mattered, and pulled concrete SKU examples.

It was not perfect, which is where the product work gets interesting.

For example, duplicate row filtering was happening in the parser, but the tool was not surfacing that filtering metadata back to the model. So ChatGPT could give the right count, but it could not explain that duplicate FBM/MFN rows had been excluded or why.

That is exactly the kind of small detail that matters in agentic products. The model does not just need data. It needs the context around the data.

So I added scan metadata that explains when duplicate rows were excluded, how many were excluded, sample SKUs, the reason, and the strategy. Now future summaries can say what happened instead of silently compressing the nuance away.

The connector work also moved toward OpenAI submission readiness: tool annotations, reviewer demo account, golden prompts, OAuth metadata, privacy/terms materials, and a cleaner public MCP endpoint. The next step there is formal review submission.

That has been a useful forcing function. A tool can feel “done” in the terminal and still need a lot of work before it is ready for an AI surface where the user may never see the raw machinery.

This work is public in a few places now. My GitHub has the early pieces of the Amazon agent stack: Catalog CLI, Keepa and DataDive adapters, SmartScout, an ads SKU migration tool, and SkillCrate itself. SkillCrate is the most direct expression of the larger idea: a free, open-source marketplace where the user is not a person clicking buttons, but an AI agent looking for structured skills it can actually call.

That line has become important to me:

Software built for agents, not retrofitted for them.

For Amazon work, that means skills with schemas, field masks, pagination, manifests, MCP surfaces, and setup instructions an agent can follow. The first wave is small: catalog auditing, Keepa monitoring, DataDive-style keyword intelligence, SmartScout market intelligence, and Amazon Ads workflows. But the direction is clear. If agents are going to do real work, they need tools designed around structured inputs and outputs, not screenshots and vibes.

The Vault Became an Operating System

The third thread is more personal and probably the most important for my own workflow: the Voartex vault has become an agent command center.

I wanted one place where agent work did not disappear.

The status language is simple:

• Backlog

• Ready for Agent

• Agent Working

• Needs Review

• Approved

• Rework

That sounds like a task board, but the actual use case is more specific. It is a way to coordinate agents, generated reports, daily review, and human decisions inside the same place I already think.

The first big step was building bridges from generated client reports into reviewable task cards.

Rogue/Cowork Keepa reports now get promoted into Keepa Review task cards. Cyclops ads reports can do the same for PlantFusion ad monitoring. These scripts do not call the source systems directly. They read reports already in the vault, create or update task cards, write run logs, and feed the daily agent.

The morning flow now looks something like:

1. Keepa Review runs.

2. Cyclops Review runs.

3. The Daily Agent creates the morning note.

4. The Command Center Sweep checks whether the wiring still makes sense.

This has already surfaced an important design lesson: task systems must never silently drop work.

At one point the Daily Agent was keeping the daily note calm by capping visible tasks. That solved clutter, but created a worse problem: tasks could disappear. Once a task system drops things, your brain stops trusting it.

So we changed the behavior. Priority stays short, but overflow moves into “More From Yesterday.” That section acts like a feeder queue. It can promote tasks into priority when slots open, and anything that does not fit keeps carrying forward. “Check this out” style items move into Notes/Links instead of pretending to be tasks. “Main thing” gets promoted to the top.

That is a small change technically, but a big change emotionally. The system became calmer without becoming forgetful.

That is the balance I keep chasing.

The Pilot Layer

Helm also crossed a small but meaningful threshold: real pilot interest.

That forced a different category of work. Once someone signs up, the system needs to notice. It needs to help with onboarding. It needs to write activity back into the vault where my daily agent can see it. It needs to avoid depending on me remembering to check yet another dashboard.

So I started building the notification layer around Stripe, intake forms, calendar links, and vault notes.

The simplest version is not a real-time webhook into my local machine. That would be possible, but it adds security and setup complexity. The better first version is a daily Stripe check that writes new pilot signup notes into a vault inbox, deduplicates them, and lets the daily agent surface them in the morning.

Again, the pattern is the same:

Do not chase magic.

Build the bridge.

What My LinkedIn Posts Have Been Circling Around

Looking back at the public posts I have been making, the pattern is pretty obvious.

I keep coming back to the same few ideas:

• Helm is not another dashboard. It is an operating command center for Amazon work.

• The goal is not more data. It is the harness that turns data, tools, context, and rules into execution.

• MCPs are not interesting only because you can chat with a dashboard. They are interesting because agents can use them to check what changed, find the issue, compare it to a benchmark, and create the next action.

• Catalog CLI was the first real step: a practical Amazon pain point turned into an agent-native tool.

• The future is not perfect agents. It is agents with better loops: capture what failed, classify it, review it, then turn it into a system improvement.

That last point might be the most important one.

Most people are trying to make agents do more. I am increasingly interested in making them fail better.

Because if a failure disappears, nothing improves.

But if a failure becomes a note, a rule, a test case, a better prompt, a better source contract, or a stronger guardrail, the system gets sharper.

The Thread Running Through All Of This

The common thread across Helm, Catalog CLI Pro, SkillCrate, and the agent command center is that agents need operational context.

They need to know:

• what they are allowed to do

• what they are not allowed to do

• what evidence is expected

• where outputs should land

• who reviews them

• how failures are recorded

• how yesterday’s work becomes today’s decision

That is the real field note for me right now.

Agents are becoming easier to create. The harder and more valuable work is making them legible, reviewable, composable, and boring enough to trust.

I am less interested in whether an agent can do a magic trick once.

I am more interested in whether it can show up every morning, look at the right context, move the right work forward, leave a clear trail, and know when to ask for review.

That is what I have been building.

Not one agent.

An operating layer for many of them.

And it turns out Agentic Field Notes was probably the right name after all.

Start Small

If you are building with agents, my current advice is: do not start with autonomy.

Start with handoffs, review states, evidence contracts, and memory.

The autonomy can come later.

The trust has to come first.

If you want a simple starting point, grab the free Helm workflow pack and map one workflow you repeat every week:

Get the free Helm workflow pack

I will be using the paid side of Agentic Field Notes to unpack the actual workflows behind this: Listing Guard, Catalog Agent, ads priority checks, evidence contracts, review queues, and the operating layer that connects them.

And if you want help mapping your own stack into this kind of system, that is what Helm is for.

I spent 6 hours last Tuesday manually auditing a client’s Category Listing Report.

Line by line. SKU by SKU. Hunting for missing attributes, checking bullet points against Amazon’s RUFUS guidelines, flagging prohibited characters.

By hour 4, my eyes were blurry. By hour 5, I was questioning my life choices. By hour 6, I had a spreadsheet full of issues... and a client who needed it yesterday.

Sound familiar?

If you’re an Amazon consultant, you’ve been there. CLR audits are necessary, tedious, and absolutely **unglamorous**. They’re also expensive to outsource and error-prone when you’re bleary-eyed at 11 PM.

So I built something.

Meet CLI Light

Catalog CLI Light is a free command-line tool that audits Amazon Category Listing Reports in seconds.

Not minutes. Not “go grab coffee and come back.” Seconds.

It runs 12 different catalog health checks, outputs structured JSON (for automation), and gives you actionable fixes ranked by severity.

And yeah — it’s completely free. MIT licensed. No upsells, no freemium traps, no “contact sales for pricing.”

What It Actually Does

Upload a CLR. Run one command. Get this:

```bash

$ catalog scan {your CLR name.xlsx} --format json

{

“marketplace”: “US”,

“is_us_marketplace”: true,

“total_issues”: 47,

“total_affected_skus”: 23,

“queries”: [

{

“query_name”: “missing-attributes”,

“total_issues”: 12,

“affected_skus”: 8,

“issues”: [

{

“row”: 7,

“sku”: “XYZ.ABC”,

“field”: “brand”,

“severity”: “required”,

“details”: “Missing required field: brand”

}

]

}

]

}

```

That JSON? Your AI agent can parse it. Your Python script can process it. Your tired brain at 11 PM doesn’t have to hunt through 1,000 rows of Excel.

The 12 Checks (Yes, I Just Added 2 More)

v1.3.0 dropped a couple days ago and v2.0 dropped yesterday. Here’s what’s new:

🌍 Marketplace Detection

The CLI now auto-extracts marketplace from your CLR. Upload a file, know immediately if it’s US, CA, UK, DE, etc. Multi-marketplace sellers, rejoice.

⚠️ Bullet Awareness Checks

This one’s sneaky. It flags “soft violations” — issues that won’t get your listing rejected, but absolutely hurt conversion:

- All caps at the start: “PREMIUM QUALITY FORMULA...” (looks spammy)

- Excessive caps: >30% of text in CAPS (reads as shouting)

- Problematic special chars: Math symbols, unusual quotes, arrows (break indexing)

These aren’t in Amazon’s official requirements. But I’ve seen them tank conversion rates.

What's New in v2.0

🤖 MCP Server Support
Connect Catalog CLI directly to Claude Desktop, Cursor, or any MCP client. Your AI agent can now audit Amazon CLRs as native function calls—no shell commands, no parsing headaches.

📊 Schema Introspection
Agents can now query the CLI itself to discover available commands, parameters, and response shapes. No more stale documentation in system prompts.

🎯 Field Masks & Pagination
Scan 10,000 SKU catalogs without blowing up context windows. Request only the fields you need, paginate results, or stream as NDJSON.

🛡️ Input Hardening
Built-in validation rejects path traversal, injection attempts, and malformed input. Because agents hallucinate—and the CLI is the last line of defense.

💻 JSON-First Interface
Structured input via `--json` and `--stdin` flags. Agents generate JSON trivially. Zero parsing ambiguity.

The Full Feature List

1. Missing Attributes — Required fields you forgot

2. Missing Any Attributes— Required + conditional fields

3. Long Titles — >200 characters (gets truncated)

4. Title Prohibited Chars — Characters Amazon rejects

5. RUFUS Bullets — AI shopping assistant optimization scores

6. Prohibited Chars — Basic validation for title/brand

7. Bullet Prohibited Content — Banned chars, emojis, claims

8. Bullet Formatting — Capitalization, length, punctuation

9. Bullet Awareness — Soft violations (NEW v1.3.0)

10. Product Type Mismatch — When type and keywords don’t align

11. Missing Variations — Products that should be variations

12. New Attributes — Unused template fields you might want

Built for Automation

Here’s where it gets interesting.

CLI Light outputs structured JSON by design. That means you can:

- Pipe results into Slack notifications

- Auto-generate client reports

- Build workflows that trigger fixes

- Feed data into your own tools

I use it in my OpenClaw setup. Every morning at 6 AM, it scans my clients’ CLRs, prioritizes issues, and drops a summary in my Telegram. I wake up knowing exactly what needs attention.

Zero manual work. Zero missed issues.

Why Free?

I get asked this a lot.

“Why not charge for this?”

Three reasons:

1. It’s a scratch-your-own-itch tool.

I built this because I needed it. Charging for it would mean support, feature requests, sales calls — all the stuff that kills side projects. Free keeps it simple.

2. The real value is in the workflow, not the tool.

The tool is dumb. It checks rules. The magic is *how you use it* — the automations, the prioritization logic, the client communication. That’s yours to build.

3. It leads to better conversations.

When someone asks “how do you audit CLRs so fast?” I get to say “I built a tool.” That’s more interesting than “I use a paid service.”

The Catch (There’s Always a Catch)

CLI Light is deliberately limited. It’s the **free tier**.

It won’t:

- Fix issues for you (just finds them)

- Generate PDF reports (export CSV and make your own)

- Check every possible rule (12 queries, not 200)

- Provide a web interface (it’s CLI-only)

CLI Light is the gateway drug. If you outgrow it, you know where to find me.

How to Try It

Install:

pip install amazon-catalog-cli

Run a scan:

catalog scan my-clr.xlsx

Export JSON:

catalog scan my-clr.xlsx --format json --output results.json

Check specific issues:

catalog check rufus-bullets my-clr.xlsx

catalog check bullet-awareness my-clr.xlsx  

Upgrade to v2.0:

pip install --upgrade amazon-catalog-cli

What People Are Saying

Okay, nobody’s saying anything yet. It’s a new tool with a tiny user base (mostly just me and a few brave consultants who’ve tried it).

But here’s what I’d like them to say:

> “I used to spend 4 hours on CLR audits. Now I spend 20 minutes reviewing the output.” — *Future happy user*

> “Caught a hijacker who injected adult content into my client’s baby product listing before Amazon suspended it.” — *Future brand protection hero*

> “Finally, a catalog tool that doesn’t require a PhD to operate.” — *Future me, six months ago*

The Roadmap

CLI Light is actively maintained. Here’s what’s cooking:

- Hijacking Detection — Flag abusive language and adult content injected by bad actors

- Natural Language Queries — “Find products with bad bullets” instead of memorizing query names

- Excel Export — Formatted reports that look like the original CLR Auditor

Got ideas? Open an issue (https://github.com/BWB03/amazon-catalog-cli/issues). I read them all.

One Last Thing

If you’re an Amazon consultant still doing CLR audits manually, stop.

Not because you’re doing it wrong. Because you’re doing it *slowly*.

Your brain is for strategy, negotiation, client relationships — not hunting through Excel for missing brand fields.

Automate the audit. Keep the brain work.

Try CLI Light: github.com/BWB03/amazon-catalog-cli

Install: `pip install amazon-catalog-cli`

Questions? Reply here or ping me on LinkedIn

Brett Bohannon — Amazon consultant, automation enthusiast, builder of tools I wish existed.

This post was written by Wolverine my openclaw assistant. It might feel different but he is learning on different models. This is me, hello. Most likely post will be about this tool and the updates on it. if you want real life updates make sure to follow me on LinkedIn or X. If you are digging the tolol or think its cool, the below would be super radical.

P.S. — If you try it and find it useful, star the repo. That’s my dopamine hit. ⭐

P.P.S. — v2.0 just dropped yesterday. If you installed before today, run `pip install --upgrade amazon-catalog-cli` to get marketplace detection and bullet awareness checks.

If you sell on Amazon, you know the pain: hundreds of attributes per SKU, bullet points that may or may not be working for you, and a spreadsheet from hell called the Category Listing Report (CLR).

I just built a free, open-source tool that audits your entire CLR in seconds and tells you exactly what to fix.

Get it here: github.com/BWB03/clr-auditor](https://github.com/BWB03/clr-auditor

---

The Problem

Amazon’s Category Listing Report is a 440-column Excel spreadsheet. Every SKU in your catalog has hundreds of fields - some required, some conditionally required, some optional. Missing a required field can suppress your listing. Missing a conditionally required field can hurt your search visibility.

And then there’s RUFUS.

Amazon’s AI shopping assistant is changing how customers find products. RUFUS doesn’t just match keywords - it reads your bullet points, reviews, and Q&A to answer customer questions like “what’s the best disinfectant for kitchens?” or “is this safe for pets?”

If your bullets read like a spec sheet instead of answers to shopper questions, RUFUS may skip you entirely.

Manually auditing all of this across 40+ SKUs? That’s a full day of work. Or it was, until now.

---

What CLR Auditor Does

The tool runs two phases of analysis on your CLR file:

Phase 1: Missing Attributes

- Reads your CLR’s Template sheet and Data Definitions to know which fields are Required vs. Conditionally Required

- Uses smart filtering by product type (it won’t flag “Team Name” for a cleaning product, or battery fields for an apron)

- Automatically skips Parent SKUs, MFN duplicates, and example data

- Validates titles: checks for length over 200 characters, prohibited special characters, and duplicate words

- Flags Item Type Keywords that don’t match the Product Type

Phase 2: RUFUS Bullet Point Optimization

Based on Amazon’s RUFUS AI framework, the tool scores each of your 5 bullet points on a 1-5 scale:

- Bullet 1 should lead with a “Hero Benefit” - why should I buy this?

- Bullet 2 should state who it’s for - target audience and use case

- Bullet 3 should differentiate - why this vs. competitors?

- Checks for vague marketing language, excessive ALL CAPS, and missing specifics

- Provides specific improvement suggestions for each bullet

---

The Output

You get a clean Excel report with 3 tabs:

1. Summary - One row per SKU showing missing field counts, RUFUS score, and a HIGH/MEDIUM/LOW priority rating

2. Phase 1 Detail - Every missing field listed with the column reference and severity (red for Required, yellow for Conditional)

3. Phase 2 Detail - Each bullet point scored with specific issues and actionable suggestions

---

How to Use It

Step 1: Download your CLR from Seller Central (Catalog > Category Listing Report)

Step 2: Install the one dependency:

pip install openpyxl

Step 3: Download `clr_audtor.py` from the GitHub repo: github.com/BWB03/clr-auditor](https://github.com/BWB03/clr-auditor

Step 4: Put the script in the same folder as your CLR file

Step 5: Update the filename at the top of the script to match your CLR file

Step 6: Run it:

python3 clr_auditor.py

Step 7: Open `CLR_Audit_Report.xlsx` and start fixing

---

Real Results

When I ran this against a real catalog with 43 SKUs:

- 28 SKUs were audited (after filtering out parents and MFN duplicates)

- Found 58 missing required fields and 960 missing conditional fields

- 6 SKUs had zero bullet points - completely invisible to RUFUS

- The best-performing product scored 4.2/5.0 on RUFUS readiness

- The worst scored 0/5.0 - no bullets at all

The whole audit took about 3 seconds.

---

Why This Matters for RUFUS

Amazon’s RUFUS is an AI shopping assistant that pulls from your Product Detail Page to answer customer questions. The old way of keyword-stuffing is dead. RUFUS wants:

- Bullets that read like answers to FAQs, not feature lists

- Specific claims with numbers (percentages, counts, dimensions)

- Clear statements about who the product is for and why it’s different

- Complete, standardized attributes so it can compare your product fairly

If your listing doesn’t give RUFUS good evidence, it will recommend your competitor instead.

---

What’s Next

This is v1.0. Some things I’m considering for future updates:

- AI-powered bullet rewrite suggestions (using an LLM to generate optimized copy)

- A+ Content analysis

- Competitive comparison scoring

- A web interface so you don’t need Python installed

If you find this useful or have feature requests, drop a comment or open an issue on GitHub.

Get the tool: github.com/BWB03/clr-auditor](https://github.com/BWB03/clr-auditor

This post was written mostly by AI - I do this because it saves me time! - This message is real written By Brett Bohannon

If you think someone will find this useful - share this with them

Share

If someone shared this with you - support in form of a free subscription is greatly appreciated

Subscribe now

If you want to chat send me a message

If you sell on Amazon long enough, you’ll eventually hit this: Amazon tells you to switch from their sticker barcodes (FNSKU) to manufacturer barcodes (UPC/EAN). Maybe you’re consolidating listings. Maybe Amazon is pushing you toward it. Either way, you comply.

Then your ads break.

Not visibly. Amazon won’t send you an alert. But your Sponsored Products and Sponsored Display campaigns are still pointing at the old SKUs — the ones tied to the sticker barcode. The new manufacturer barcode SKUs? They’re sitting there with zero ad coverage.

And if you have dozens of campaigns across multiple products, you’re looking at hours of manual bulk sheet editing to fix it.

I had exactly this problem last week. 98 Product Ad rows across 56 campaigns needed new SKUs. Here’s how I solved it in about 30 seconds.

The Problem

When you switch barcode types on Amazon, your SKU changes. For us, every SKU got an “A” suffix — XYZ/20 2 became XYZ/20 2A, CV112-60 became CV112-60A, and so on.

But Amazon doesn’t let you update a SKU on an existing Product Ad. From their own docs:

“You can’t update a SKU or ASIN, but you can pause or archive the associated product ad entity and then create a new one with the SKU or ASIN you want to add.”

So for every Product Ad in every campaign, you need to create a new row with the updated SKU. Manually, that means:

• Download your bulk file from Amazon Advertising

• Find every Product Ad row (buried among campaigns, ad groups, keywords, and targeting rows)

• For each one, create a new row with the exact same Campaign ID, Ad Group ID, and the new SKU

• Make sure you set Operation to “Create” and Entity to “Product Ad”

• Handle the fact that Sponsored Products and Sponsored Display have different column layouts (Ad Group ID is column E in SP but column F in SD)

• Upload the file and pray you didn’t miss anything

For 98 rows? That’s a full afternoon of error-prone spreadsheet work.

The Solution

I built a Python script that does all of this automatically. It reads your Amazon Advertising bulk download, finds every Product Ad row, and generates upload-ready files with the new SKUs.

Here’s what it does:

1. Reads your existing bulk file — the same .xlsx you download from Campaign Manager > Bulk Operations

2. Finds all Product Ad rows across Sponsored Products and Sponsored Display sheets

3. Generates new rows with the correct column mapping for each campaign type

4. Handles edge cases automatically — skips SKUs that already have the new suffix, filters out FBA error entries, avoids duplicates where the new variant already exists

5. Outputs two files: a full migration file and a single-campaign test file

The test file is key. Upload that first, verify the new Product Ad appears correctly in one campaign, then upload the full file once you’re confident.

What About Sponsored Brands?

This was an important discovery during the process. Sponsored Brands campaigns don’t use SKUs — they use ASINs. Your ASIN stays the same regardless of barcode type. So SB campaigns continue working without any changes.

Only Sponsored Products and Sponsored Display need migration.

The Numbers

For our account, the script found:

• 96 existing Product Ad rows across Sponsored Products

• 16 existing Product Ad rows across Sponsored Display

• 98 new rows generated (after excluding SKUs that already had the suffix, FBA errors, and duplicates)

• 0 manual edits required

Total time from running the script to having upload-ready files: about 30 seconds.

How to Use It

The tool is free and open source: github.com/BWB03/amazon-ads-sku-migration

pip install openpyxl
python generate_sku_migration.py your_bulk_download.xlsx --suffix A

Replace A with whatever suffix your new SKUs use. The script auto-detects the best campaign for your test file, or you can specify one with --test-campaign.

The Recommended Workflow

1. Download your bulk file from Amazon Advertising (Campaign Manager > Bulk Operations)

2. Run the script — it generates a TEST file and a FULL file

3. Upload the TEST file (one campaign, one new row)

4. Wait 24-48 hours and verify the new Product Ad appears correctly in the Amazon console

5. Upload the FULL file once the test passes

6. Later: archive the old SKU Product Ads in a separate bulk operation

Step 6 is important but separate. Don’t rush it. Let the new ads run alongside the old ones until you’re confident everything is working.

Technical Details for the Curious

A few gotchas that the script handles so you don’t have to:

SP vs SD column differences. Sponsored Display uses column F for Ad Group ID and column P for State. Sponsored Products uses column E for Ad Group ID and column R for State. Get these wrong and Amazon will reject your upload or worse, create ads in the wrong ad groups.

Duplicate prevention. If you already have some new-SKU Product Ads live (maybe from a partial manual migration), the script checks each ad group and skips any where the new SKU already exists.

FBA error entries. Bulk downloads sometimes contain SKUs like FBA18LF1SBG2.Missing1. These are Amazon system artifacts, not real Product Ads. The script filters them out.

Header preservation. Amazon’s bulk upload is finicky about headers. The script copies headers exactly from your source file — same columns, same order, same casing.

This is the kind of operational work that eats up hours if you do it manually and takes seconds if you script it. The barcode transition itself is straightforward. The ad migration is where sellers lose time.

If you’re dealing with this, grab the tool: github.com/BWB03/amazon-ads-sku-migration

This post was written mostly by AI - I do this because it saves me time! - This message is real written By Brett Bohannon

Subscribe now

The “Scroll-Stopper” Problem

If you sell on Amazon or run social ads, you know the drill. To get someone to stop scrolling, you need high-end, 3D motion graphics. You need the product floating in zero gravity, ingredients exploding in slow motion, and liquid physics that look like a Super Bowl commercial.

Usually, that costs $5,000 and takes three weeks of rendering time.

Last night, I built one in 10 minutes. For free. ( well almost free, I think it cost about $3 )

I want to show you exactly how I did it using a new workflow I call “The Impossible Ad Framework.” I’m going to use a fictional energy drink brand I invented called “Nebula” to demonstrate the process, but you can use this for protein powder, skincare, or tech gadgets.

Here is the breakdown.

Step 1: The “Anchor” (Separation of Church & State)

The biggest mistake people make with AI video is trying to do everything at once. They ask the video model to “Make a video of a Nebula energy drink.”

Don’t do that. Video AI is amazing at movement, but it is terrible at spelling. If you ask it to generate your logo, it will hallucinate the letters.

Instead, we use an Image Generator (like Midjourney or Gemini) first to create a perfect, static “Anchor Image.”

Note: You can use your Main Image on Amazon for this

The Prompt I Used:

“Professional product photography of a single sleek matte-black slim beverage can. The word ‘NEBULA’ is written vertically in glowing neon-purple. Fresh condensation. High-key studio lighting, isolated on a solid plain white background. 8k resolution.”

The Result:

Step 2: The Engine (Google Veo 3.1)

Once I had my anchor image, I went to Google AI Studio and selected the Veo 3.1 model.

This is the secret sauce. Veo 3.1 has incredible “physics” understanding. It knows how liquid splashes, how ice cracks, and how objects float in zero gravity.

I uploaded my Anchor Image and used a “Physics-Based” prompt. I didn’t describe the product (the image did that); I described the action.

The Video Prompt:

“Cinematic 3D product commercial. The can spins slowly in zero gravity. Surrounding it, crystalline ice cubes and glowing purple blackberries explode outward in slow motion. A ribbon of violet liquid swirls helix-like around the can. Rim lighting, 4k resolution, Unreal Engine 5 render style.”

One thing I hate is having to edit video even further for Amazon requirements, below is what to include i the prompt:

Tech specs to include: 
Video dimensions	1280x720, 1920x1080, or 3840x2160px
File size	500MB or less
Aspect ratio	16:9 (square pixel) only
Video codec	H.264 or H.265
Video profile	Main or Baseline
Frame rate	23.976, 23.98, 24, 25, 29.97, 29.98, or 30fps
Video bit rate	Minimum 1 Mbps (4 Mbps or higher recommended)
Video scan type	Progressive
Audio codec	PCM, AAC, or MP3
Audio format	Stereo or mono
Audio bit rate	Minimum 96 kbps
Audio sample rate	Minimum 44.1khz

The Result:

Look at the liquid physics. Look at the lighting. That used to take a team of animators days to build. Veo did it in 40 seconds.

Step 3: The Psychology (The Script)

Pretty visuals stop the scroll, but copy gets the sale.

I don’t just throw random text on the screen. I use a specific 3-step script formula designed to validate the customer’s pain before selling them the solution.

The “Nebula” Script:

1. The Hindsight Hook (0:00): “Weird how your ‘energy’ drink always makes you tired by 2 PM.” (Expose the blind spot).

2. The Validation (0:03): “You didn’t need more caffeine. You needed better fuel.” (Remove the guilt).

3. The Simple Path (0:06): “Nootropics + Hydration. Zero Crash. Welcome to the future.” (Present the new solution).

Step 4: The Assembly

Finally, I dragged the AI video into CapCut.

Since I generated the “Anchor Image” on a white background, the AI kept the edges perfectly clean. I added a deep space background, overlaid the script text, and added some “Whoosh” and “Liquid Pour” sound effects to sell the realism.

Total time: ~20 minutes.

Total cost: ~$3.

Want to try this yourself?

I put together a complete “Impossible Ad” SOP that breaks this down step-by-step. It includes:

• The exact prompts for Veo (Exploded Views, Impact Shots, etc.).

• The 3-Step Scripting Templates.

• How to fix glitchy logos in post-production.

LINK: Download the Master SOP Here - make a copy to edit

LINK: Watch the Full Nebula Video Example Here in Canva

The barrier to entry for high-end creative is gone. The only limit now is your strategy.

Here is the deal… I did use AI to help me with this post ( this right here is not AI written) I used it so I can do something that usually takes me an hour to do it in half the time. The best part.. its not slop this is everything I did, hours of work condensed into a quick read / blueprint to make rad videos. I sure hope I see one like this on Amazon soon.

Here is another deal, will you have to put some work in it? Yes, but at the same time once you do the process a few times it will only get easier. Heck, you might even be abel to make the process faster than me. I hope so.

Going forward I am going to use my field notes as just that… what I am doing with AI, how it is helping me. I will share the journey of what I am doing, and the end goal is simple: Use AI to make it so I have more time to do do the things outside of work that I like to do.. while scaling my business. It’s quite simple… Im a solo guy with a book of business of about $20k MRR. I want to get to $30k and eventually $40k while not loosing my mind. You know how I am going to do it? Im going to tinker with AI and make my own virtual assistant / employee, minimize my expenses on software in the Amazon space and expanding my offerings. I see gaps in the market when it comes to what Brands and Sellers need on the marketplace and I am currently working to fill those gaps.

I will no longer paywall the juicy posts… You can implement everyone of these and get awesome results, tinker and try to gain some time back while the output stays the same or increases. If you feel that someone you know would like this… then do me a favor send them this post and have them subscribe for free.

While my post will be focused in the Amazon space anyone can take the ideas and implement similar ones in whatever field they are in.

Appreciate you reading this and appreciate you!

- Brett Bohannon

Google just dropped something quietly powerful that most people missed: Workspace Studio, a no-code agent builder that essentially gives you a personal executive assistant trained on your exact workflow. Instead of drowning in calendar notifications, task lists, and email threads, you can build agents that actually do the grunt work—like sending you a morning briefing of today’s meetings with attendees and Zoom links, or pinging you 15 minutes before a sync with a cheat sheet of your last conversation with those people. These aren’t just fancy filters or zapier-style automations; they’re contextual agents that read your Google Calendar, Gmail, Drive, and Sheets, reason about what matters, and surface the right information at the right time. The wild part? You build them by typing plain English instructions. Below are the exact prompts I’ve been testing to turn Google Workspace into something that finally feels like it’s working *for* me instead of just piling up more tabs.​​​​​​​​​​​​​​​​

Here are the prompts to make your own assistant:

Idea A: The "Day-of" Calendar Briefing

* The Goal: You want an email (or Chat message) summarizing your day so you don't have to open the Calendar app.

* Prompt to type in Studio:

> "Every morning at 8:00 AM, look at my Google Calendar for today. Summarize the meetings into a list including the time, attendees, and any Zoom/Meet links. Send this summary to me in a Google Chat message."

>

* Why this works: It uses a Time-based trigger and connects Calendar to Chat. (I recommend Chat over Email for this; it feels more like a real assistant whispering in your ear).

Idea B: The "Task Master"

* The Goal: A morning report of tasks and priorities.

* Prompt to type in Studio:

> "Check my Google Tasks (or a specific Google Sheet where you track tasks). Count how many are due today. Identify which ones are marked 'High Priority' or contain the word 'Urgent'. Send me a summary in Chat saying 'You have X tasks today. Focus on these three first: [List]'."

>

2. Advanced "Assistant" Ideas

To really make this feel like a human executive assistant, you should leverage the tool's ability to read content (Drive/Docs) and reason (Gemini).

The "Meeting Prepper" Agent

Instead of just knowing when a meeting is, this agent prepares you for it.

* The Prompt: "15 minutes before any event on my calendar with 'Sync' or 'Update' in the title, find the last email thread with those attendees. Summarize the last 3 emails and DM me a 'Cheat Sheet' so I know what we discussed last time."

* Why it's powerful: It saves you the panic of searching "what did we talk about?" right before a call.

The "Inbox Gatekeeper"

Stop drowning in noise. Create an agent that triages for you.

* The Prompt: "When I get an email from [Boss's Name] or [Key Client Domain], scan the text. If it asks for a meeting, draft a reply offering my next 3 available slots from Calendar and save it as a Draft. Then ping me on Chat saying 'Draft ready for [VIP Name]'."

The "Project Watchdog"

If you manage projects in Sheets, don't check them manually.

* The Prompt: "Monitor the 'Project Alpha' Google Sheet. If the status column changes to 'Blocked' or 'Red', alert me immediately in Chat with the row details."

The "Out of Office" Buffer

* The Prompt: "If I receive an email while my Calendar status is 'Out of Office', reply automatically, but also add the sender's name and request to a 'To-Do' list in Google Docs named 'Post-Vacation Catch-up'."

How to Start

* Go to the Workspace Studio link

* Look for a button like "Create new agent".

* Start simple: Try the "Morning Calendar Briefing" first. It is the easiest to verify if it's working correctly.

* Iterate: If the agent gives you too much info, just tell it (e.g., "Edit the agent to only show meetings with other people, ignore my solo focus time").

Overall, September was a crazy month for testing a bunch of new AI tools that were built to help customers’ needs, well mostly mine to help customers. One thing that really lit me up was creating a digital avatar for content creation on YouTube. {insert link}

This has lit me up for many reasons — mostly due to the fact that I have always wanted to start more content on YouTube but at the same time I didn’t want to be in front of the camera all the time. I like to be active, be with my family, and surf/snowboard a bunch. I never wanted content to bleed into any of those things. I am still on the journey of 80/20 — I want to have AI do 80% of my work so I can focus on the 20% that lights me up.

So let’s dive into the field notes.

Dashboard for SKU Economics — Big One I’ve Been Working On

Sellers don’t want to include COGS in Amazon. This way you can own your data and include the entire picture per unit. Other tools already do this, but you can build it yourself.

Here is the prompt idea I put into Claude to help build this out. You can do the same and start building it out yourself. I will be following up with a blueprint of this soon.

can you create a different version of this tool.. can you Create to follow the below parameters:
Upload CSV file for SKU economics
input total spend - via report
input COGS for each ( this is tricky with multiple skus)
This will be great for One sku catalogs
Here is the tricky part for multi sku catalogs... we would have to input a asin spend report for all advertising.... Also for the COGS per sku
Here are a couple reports attached - sku economics without spend and Total spend based on asin
you will have to have this tool look at both reports and then do a total high level economics for whatever date range that is supplied and also break it down
if you have any ideas around the inputting cogs per sku that would be helpful
The goal here is to not input COGS into amazon and the user has complete control over the report.
I want to keep it simple and not overcomplicate the tool 

Here are the different instructions I want to include: 

Access the SKU economics report 
Menu 
Reports 
Selling economics and fees 
SKU economic report 
Have the report include the below 
Will want to have the child asin the data aggregation level possibly due to ads report ( i might switch this to msku, it might be easier to ID products) 
Date range is whatever they would want to include

The Issue: The SKU report only includes SP, not other spend. How do you create it all? Through Mixshift reports or other tool reports for a quick and easy dashboard using the SKU economics download report.

I have been going through a lot of revisions with this tool, almost to the point that it doesn’t make sense, but I think it could be a solid choice so you don’t have to pay for a service. A repository would be the best option to keep this fluid.

Going to pivot from this as this is going to be a larger build and I’m not sure if it’s worth it to be honest. This works great for one SKU catalogs, but working with multi-SKU has added a layer of complexity and I will keep attempting to dial it in to share. I might even share where I am and provide updates as I go along. Lots of issues while building it.

AWD and FBA Inventory Dashboard

How to create a quick snapshot of AWD and FBA inventory — full picture.

Old way: Download both reports and check in Excel
New way: Check your inventory level across both AWD and FBA

As far as I know, the AWD and FBA inventory reports act as separate entities and you can only pull them via API. This tool solves this and allows you to manually import the two reports to get a full picture of your inventory.

Use cases: Inventory planning for AWD and FBA

Here is a full blueprint for the build :

Creatives and AI

Don’t take it from me — I asked Daniella from Mindful Goods how she handles AI and her answers are awesome!

I sent over a few questions about AI and Creative to the queen of creative in the Amazon space, Daniela Bolzmann, and her responses were awesome! Everyone thinks that they can become their own creative agency now, and some might, but honestly I still trust real creative agencies these days.

Enjoy the answers to the questions

Overall Content Creation

Lately my LinkedIn reach has been dismal, not sure why, but it got me thinking about YouTube.

My new goal is to automate 80% of the daily work so I can focus on doing the things I love in my life and business. I started to play around with AI avatars via HeyGen to make content — specifically YouTube content.

My biggest hangup with YouTube was being in front of the camera all the time. This has allowed me to set up an avatar and provide a script. I will share the process in a separate free post very soon.

Showcasing the difference of the two prompts: I was given the prompts and ran with them as-is. I did not like the results, so I created a better version. You can see the difference in version 1 and version 2 on the sheet.

Prompt - multiple versions

I took both versions and ran them through Claude to ask which one is better and why in regards to formatting and context. Need to clean this up and have version 1 and version 2 to show the difference.

Seller Support Blueprint

Here’s a tease of what’s coming.

I built this out for a client and will provide the blueprint in a couple weeks. The tool was for the client, so the blueprint will be one that you can use to create for yourself. Blueprint will give you the breakdown of it — you will have to tweak it and can do so by following the steps on the blueprint.

The Results: The first couple attempts on this tool meant I had to follow up with support more. After 2 iterations, seller support made the changes on the first try. I created this as I needed to perform the same task multiple times — I reduced my time on it by 50% by creating this tool. This made me more efficient when dealing with seller support.

Simple structure for this:

• Create a project in Claude

• Include PDF of any correspondence you have had in cases with seller support around this (this provides feedback from seller support with your AI chat)

• Include any main requirements from Amazon (think links to requirements/TOS/explanations) — this will also be in PDF form

• Create a prompt that could be as simple as the below

• This will provide a full feedback loop

• Seller support can be finicky, so multiple attempts might be required

Full prompt and full build blueprint:

Simple prompt ( edit as necessary) :

Situation You’re managing a product compliance project requiring multiple support case submissions for label updates. 

You have 3 successful case examples that established an effective pattern.

Task Create a reusable support case template based on the successful examples provided, plus a streamlined process for efficient batch submission.

Objective Enable rapid, consistent case submissions using a standardized template that mirrors your proven approach.

What You’ll Provide Reference your three successful PDF cases so I can identify:
Effective language and structure
Required information fields
Optimal tone and terminology

What You’ll Receive

A fill-in-the-blank template with placeholders for variable product information

A step-by-step workflow optimized for processing multiple cases efficiently

Next Step Share the 3 PDF case examples to begin template extraction.

Note: On the paid tier, I can help you walk through any troubles you have with seller support.

Looking Forward

September reinforced that not every AI experiment needs to be perfect out of the gate. The SKU economics tool is still evolving, the YouTube avatar is opening new content possibilities, and the seller support blueprint is proving its value in real client work.

The key is documenting what works, what doesn’t, and why — then iterating until you find something that sticks.

Found this useful? Share this post with other sellers who might benefit from these experiments. The more people testing and building, the better tools we all get access to.

You can access a 14 day free trial to paid post by clicking here : https://agenticfieldnotes.substack.com/b8791329

These field notes document real AI experiments from my Amazon consulting practice. Questions about any of these tools or want to follow along with more practical applications? Consider the paid subscriber tier for detailed blueprints and implementation support.

Questions or ideas: brett@voartex.com

This blueprint will guide you through building a fully functional, browser-based inventory dashboard that combines Amazon FBA (Fulfillment by Amazon) and AWD (Amazon Warehousing & Distribution) inventory data into a single, comprehensive view.

Build Time: 1-2 hours
Cost: $0 (completely free to build and host)
Technical Level: Beginner-friendly (no backend coding required)

🔥 The Problem This Solves

Current Pain Points:

• Amazon doesn’t provide a combined view of AWD + FBA inventory without API access

• Sellers manage inventory across two separate systems

• No unified reporting for total available inventory

• Manual spreadsheet consolidation is time-consuming and error-prone

• Difficult to get a quick snapshot of overall inventory health

The Solution:

A self-service dashboard where users upload both reports and instantly get:

• Combined inventory totals

• Visual charts and analytics

• SKU-level detail across both warehouses

• Days of supply calculations

• Inventory health indicators

Value Proposition: This tool is worth hundreds of dollars as a SaaS product, but you’ll build it for free and can use it yourself or offer it as a service.

🎨 What You’ll Build

Read more

Daniela Bolzmann is the founder of Mindful Goods, a creative agency that has worked with more than 500 brands to optimize their Amazon presence. With clients ranging from venture-backed startups to established 8-figure brands, Daniela has built production workflows that combine traditional design expertise with emerging AI capabilities.

What makes this conversation valuable isn’t just the scale—it’s how thoughtfully she’s integrated AI into workflows that still prioritize quality and client results. This isn’t about replacing creative teams with AI. It’s about solving problems that were previously unsolvable.

Here’s what she shared about how AI is changing creative production for Amazon brands.

Creative Production at Scale

With your agency handling creative content for 7 & 8 figure brands, how has AI changed your production workflow? Are you using AI for initial concept generation, A+ content ideation, or product image enhancement—and what’s been the biggest efficiency gain versus quality trade-off you’ve navigated?

Our production process has changed and will continue to change as new tools improve and become available. The gains we are seeing are in creativity, ideation and scaling creatives. Using AI for creatives still takes time and requires us all to improve our prompting skills so it’s just another tool in our tool belt.

We’re using AI in a few different ways. The top three that come to mind that are most notable and probably the easiest for most people to use is:

1. MAIN IMAGE IDEATION

We use AI for ideation of main images. We’ve trained our own AI tool off of our best-performing main images so that we can drop a client’s main image into this tool and it will essentially analyze it and spit out 15-20 other types of mockups that are based off of our best-performing main images across various different categories. Using this kind of process, we’re now able to in a matter of minutes show the creative director and the client various different outputs that get the wheel spinning. Most of these are not final polished images, but it’s a really great way to quickly ideate and get the wheel spinning in the right direction for coming up with some solid concepts that we can then split test in a tool like PicFu before uploading to Amazon’s Manager Experiment tool.

2. LIFESTYLE IMAGERY

The second way that we’re using AI in our creative process is to create lifestyle images that the client may not have or needs in a pinch. This could be when there’s scenarios where the client might not have time to do a photo shoot, and we can help them create some AI imagery to fill in the gaps with their creative content. There’s also times where the budget doesn’t allow for it, so this can be a great way to fill in the gaps with any content. And there’s another scenario where clients may have maybe changed their packaging, and they’ve already done a photo shoot and have these amazing images that they want to use, but they’re not able to use them because they’ve upgraded their packaging or changed their label in some kind of way. Well now with AI we can easily make those swap outs or make tiny adjustments to the images that they need on the fly. So that’s another scenario where we might use AI to help generate some imagery that’s actually trained off of the client’s own product photography which is a really great use case.

3. SCALING CATALOGS

The third way that we’re using AI is that we are in the past we’ve had clients come to us with very large catalogs (hundreds or even thousands of SKUs) and we’ve typically had to turn down this business because we would be working on it for months and months and we wouldn’t be able to get the price points where the client would want it. What we do is a very boutique style of design service at Mindful Goods. Well, now with certain AI tools, we’re now able to scale our creative process. We still have to create the master (let’s say templates) for the products that we’re working on, but now if a catalog has another 50 to 500 variations under that product, we can now use AI to essentially bulk generate or bulk scale our creatives across the catalog. That’s probably the most exciting use case that I’m exploring at the moment because it’s something that we’ve just never been able to do.

Client-Facing AI Integration

Since Amazon now sends you clients directly and you’re working with venture-backed brands, how do you position AI tools when clients ask about them? Have you found ways to use AI for competitive research or keyword optimization that deliver measurable results you can show clients?

Yes, there are a couple of fun ways that I love using AI. When clients ask about AI tools, we generally let them know that it’s one of many tools in our tool belts that we apply in different ways throughout our entire process.

There are the three ways that I mentioned above, but there are a couple of additional ways that I like using them for the research stage or the keyword optimization stage. One of them is using a tool called Voc.ai. Voc will basically do a competitive analysis, very similar to a tool like Helium 10 or Datadive, but it creates these visualizations. I like taking the visualizations and scraping the reviews, and then doing an AI analysis using a tool like Perplexity to pull out all of the highlights and things that might be interesting to analyze. Once we have all of that, we can then populate the visuals and the analysis or the highlights into a visual dashboard using an AI tool called Lovable (which is basically a vibe coding tool that allows you to easily create robust dashboards and visuals with the help of AI).

I find that using something like this makes everything much more digestible for the customer rather than sharing a bunch of spreadsheets and documents and all of that which we’ve typically done in the past with the help of a Loom video to guide clients through. But now if we can do it in more of a visual way, it’s just easier for the client to process that information. It’s also creating a sounding board for the creative director to then come back and utilize really quickly when we have to make data-driven decisions on what we’re doing with the content. So it can be a really great way for us to have something to cross-reference that has a foundation of data.

Operational Workflows Behind the Scenes

Your case studies show incredible results like 656% order surges and 2484% growth—are you using AI anywhere in your client management, project coordination, or analysis processes that help you deliver these outcomes more consistently? I’m thinking about things like processing client feedback, managing revisions, or tracking what’s working across different campaigns.

This is a really good question. Where my head is at right now is that we use third-party tools like PickFu, ProductPinion, and Intellivy to run split tests quickly. Usually they take an hour or less, and that helps us while we’re designing before we upload anything to Amazon to understand if what we’re designing is effective.

The problem with these tools is that any given test can cost anywhere from $50 to a couple hundred dollars depending on how many pollers you have taking your split test. It can be a cost-prohibitive activity depending on the budget that the brand has, and they might look at it as a nice-to-have and not a mandatory part of the process. For us, we know how valuable this is, and we know that this is one of the ways that we can assure that the content will perform on Amazon, so we love using these types of tools. But even for us as an agency, we have to budget for that.

What’s interesting for me is that now with AI, you can essentially use the data from the brand (all the data that’s online about this brand, the reviews on their website, the reviews on Amazon, the reviews on Reddit, any conversations that are happening in forums). AI can understand the customer and build avatars around these customers, which means that it can then use that data to build custom avatar audiences that are built exactly off of the data for this brand. Once we have that, we can essentially run split tests at a much more cost-effective price or output and we can run them almost unlimited. We can run as many as we want or need.

What I’m excited for is more design tools to be building that into the process of design, and I think that that’s going to be something that’s coming soon. The AI audiences based on avatars is already here, so that’s really exciting and it’s something that we’re exploring at the moment.

Why This Conversation Matters

Daniela’s approach demonstrates something important: AI integration at the agency level isn’t about replacing creative expertise—it’s about solving previously impossible problems.

Before AI, her agency had to turn down clients with large catalogs because the economics didn’t work. Now those projects are viable. Before AI, split testing was cost-prohibitive for many brands. Now it’s becoming accessible through customer avatar modeling.

This is the kind of practical AI application that changes business models, not just workflows.

About Daniela Bolzmann: Daniela is a leading expert in Amazon brand optimization and the founder of Mindful Goods, a creative agency that has helped more than 500 brands elevate their content and grow on Amazon. With a background in marketing, tech startups, and e-commerce, Daniela developed a results-driven approach to Amazon listing optimization, making her a go-to consultant for entrepreneurs and brands aiming to succeed in the competitive Amazon marketplace. She is also a recognized speaker and educator, sharing actionable insights and strategies for boosting conversions and creating compelling product presentations that connect brands to consumers.

Check out her company here → https://mindfulgoods.co/

This is a guest conversation in the Agentic Field Notes series. Want to share your AI experiments in Amazon? Email brett@voartex.com

*New here? - check out all the post below