What AWS Partner Central Agents Read in Your ACE Pipeline

There is a sentence in AWS’s API reference that tells you more about how co-sell now works than any announcement has.

The field is called CosellMotion. It appears on the AWS view of your opportunity, and AWS describes it like this: “Engagement classification for this opportunity. Read-only. Null before scoring. Known values: AWS Field-engaged, Agent-engaged, Partner-led.”

Read it twice. How AWS is engaging with your deal is a value that gets computed, it is not writable by you, and until something scores your opportunity it does not exist at all. Whatever your relationship with your partner manager, the record of how AWS engages this deal starts as null.

What was actually shipped

AWS Partner Central agents launched on 16 March 2026, built on Amazon Bedrock AgentCore. The launch post describes four things the agents do: deliver pipeline intelligence conversationally, help create opportunities, progress deals, and find funding you qualify for. A second release on 16 June 2026 added a fifth: submit leads in Partner Central and get propensity insights back, along with recommendations on which leads are eligible for programs and funding. On 20 July 2026 the funding agent was extended to every AWS Partner funding programme, adding Strategic Collaboration Agreements and the AWS Growth Initiative to the four it launched with.

Three releases in four months, and the cadence is the point. This is not a feature that shipped and settled; it is a surface AWS is still building out, which means the answer to “what do the agents read” will keep widening.

The mechanics are worth stating plainly, because the announcements are written in the register of a product launch and the consequence is operational.

On creation. You describe a deal in plain language, upload meeting notes or a proposal, or clone an existing opportunity, and the agents extract the details, validate them, populate customer information, and recommend improvements before submission.

On progression. You upload transcripts, notes or emails and the agents populate the relevant opportunity fields for you, and generate sales plays on demand.

On scoring. Every opportunity carries an Opportunity Quality Score. AWS is unusually specific about what it measures: “Deal quality score based on opportunity content completeness and sales methodology criteria. Values range from 0 to 100.” It carries a Trendalongside it — Improving, Declining, or No Change — and the June post states that opportunities are continuously rescored as you improve your submission data, which for an Agent-engaged opportunity “can move you closer to AWS Field-engaged as your score strengthens.”

That last clause is the mechanism. AWS calls the score “a key input into which co-sell motion your opportunity receives” — so the classification that governs whether an AWS seller engages your deal is downstream of something computed from what you wrote down.

Agents act on fields, not on relationships

This is the part that gets lost.

Partner organisations have spent fifteen years building a co-sell practice out of relationships. You know your partner development manager. Your solutions architect has worked three deals with theirs. When something needs to move, someone picks up the phone. All of that is real, and none of it is legible to a language model reading an opportunity record.

AWS brings its own material to the record — propensity insights on submitted leads, solution scores, program eligibility. But the half that describes your deal is the half you wrote: CustomerBusinessProblem, TargetCloseDate, NextSteps, CustomerUseCase, ExpectedCustomerSpend, DeliveryModels, and the customer’s AwsAccountId. An agent cannot infer from a sparse record that this is your best deal of the quarter, because the sparseness is part of what it was built to measure — content completeness and sales methodology criteria, on a scale of nought to a hundred.

So a pipeline that a human partner manager would describe as strong, and an agent scores as weak, is not a disagreement. They are reading two different objects. One is reading a relationship that exists in the world; the other is reading a record that mostly doesn’t.

This is a change in what “good pipeline hygiene” is worth. Filling in fields used to be an administrative tax you paid so that reporting worked. It is now the input to a scoring function that decides how AWS engages. The same activity, repriced.

The field nobody filled in

Here is the concrete case, and it is the sharpest evidence available that this is already costing partners a capability they cannot retrofit.

Revenue Attribution IDs are the layer AWS uses to map measured revenue to the specific deals you are requesting deal-level incentives on. AWS lists five prerequisites for creating and using one, and one of them reads, verbatim: “An opportunity in Launched stage with a customer AWS Account ID specified (for ACE opportunity associations).”

Two conditions, and the second one is the trap. The API marks AwsAccountId as not required, and in our experience it is not a field most partner organisations have been disciplined about — nothing downstream chased it. An opportunity could go all the way to Launched, the stage that means you won and the workload is live, with that field empty, and nothing anywhere would tell you.

Now it is a prerequisite for the deal-level attribution layer. And the opportunities it applies to are, by definition, the ones already in Launched stage: closed, delivered, historical. You cannot go back and collect an account ID from a deal you won eighteen months ago with the energy you would have spent collecting it at the time.

This is what “agents act on fields” costs when it is not abstract. Not a worse score — an unavailable capability, on revenue that has already been earned and measured.

The deal-level attribution layer covers the rest of that mechanism, including why multi-tenant SaaS has no alternative to it.

What migration has to do with it

One prerequisite governs everything above, and it is stated in the launch post without emphasis: “Agents are available today for Partners who have migrated to the new AWS Partner Central experience in the AWS Console.”

Not a rollout note. A hard gate. A partner who has not migrated has no agents, no conversational pipeline intelligence, no transcript-to-fields population, and no Revenue Attribution IDs — which carry the same migration prerequisite.

The public managed-policy changelog shows the plumbing being laid, dated. On 13 March 2026, three days before the launch post, AWS updated four managed policies — AWSPartnerCentralFullAccess, AWSPartnerCentralOpportunityManagement, AWSPartnerCentralSandboxFullAccess and PartnerCentralIncentiveBenefitManagement— each “to add Partner Central Agents session management capability through the Model Context Protocol.” On 16 June 2026, the same day as the second blog post, it updated AWSPartnerCentralOpportunityManagementagain “to add prospecting actions access.”

That changelog is public, dated, and takes about ninety seconds to read. It is the most reliable signal available about what AWS is building, because a permission has to exist before a feature can use it — which makes it a roadmap that ships slightly ahead of the announcements.

We have written separately about the migration deadline, which two vendors state as fact on dates three months apart, neither citing AWS. The position there holds here: migrate for what it unlocks, not for a date nobody can source. Agents are one of the four things it unlocks.

Where MCP fits, and where it doesn’t

Both posts point at the same integration path: partners can connect existing tools and systems directly to the agents with the MCP Server, bringing AWS intelligence into workflows teams already use. It is properly documented — a managed, AWS-hosted server with a getting-started guide, a named tool list covering sales-play generation, customer profiles, solution recommendation and funding recommendation, and human-in-the-loop approval on write operations.

This is genuinely useful and it is worth being precise about what it changes. MCP moves where you read the intelligence. It does not change what the intelligence is computed from. An agent reached through your own tooling is reading the same opportunity record, scoring it on the same criteria, and returning the same classification. Connecting it to a CRM full of thin opportunities gets you the same score, faster.

The reverse is easy to assume — that integration is the work, and once the pipe is connected the intelligence flows. The pipe is the cheap part. What travels through it is decided by what was written down when the deal was qualified.

What this actually asks of an operator

Treat the record as the deliverable, not the report of it. The opportunity record used to be documentation of work done elsewhere. It is now an input to a scoring function that decides how AWS engages. Anyone who has done SEO will recognise the shape: the thing you wrote for an audit became the thing being judged.

Collect the customer AWS Account ID at qualification. Not at Launched, where it is currently a prerequisite you discover you failed. It costs one question early and is close to unrecoverable late. The same logic applies to anything else the agents read: the cheapest moment to write it down is the moment you learn it.

Watch Trend, not Score. A score of 61 tells you little without knowing what a good one is, and AWS has not published the weights. Trend is self-relative and therefore actionable: it tells you whether what you did last week helped. Since the agent rescores as details change, a Declining trend on an active deal is a signal that arrives before the deal goes quiet.

Read null as information. CosellMotion being empty does not mean nobody is engaged. It means your opportunity has not been scored, which for a deal you consider live is worth investigating on its own.

Audit backwards once. Pull your Launched opportunities and check which have a customer AWS Account ID. That number is your exposure on the attribution layer. It takes one query, and it is the only way the number exists.

Disclosure, because we sell into exactly this gap

This piece argues that opportunity records need to be complete, and Wyra sells into exactly that. It belongs at the top of this section rather than the bottom.

Specifically: Wyra produces written insights on every prospect, with the reason a prospect was disqualified recorded alongside the ones that fit, and deals land in your CRM on ACE-native stages and sync two-way with AWS Partner Central when your team chooses to share them. So a Wyra-originated opportunity does not arrive as a thin record that has to be enriched later — the customer business problem, the why-now and the engagement detail are written at qualification, before there is an opportunity to score. We benefit if you agree with this article.

That sync runs on the Partner Central API, which carries the same migration prerequisite as the agents — so the gate described above gates us too. Connecting it is a single CloudFormation template rather than an integration project.

Two things that should temper the argument. The first is that nothing here requires us. Every move in the section above is a process change — collecting an account ID earlier, watching a trend, running one audit — and a partner who does those things with a spreadsheet gets the same result. The claim is about what agents read, not about who writes it.

The second is that everything above is checkable. The two blog posts, the API reference, the Revenue Attribution ID prerequisites and the managed-policy changelog are all public AWS pages, all linked above, and between them they take about ten minutes.

The thing to carry forward

AWS did not announce that relationships stopped mattering, and they have not. What it shipped is narrower and more consequential: a scoring function over your opportunity records, wired to a read-only field that classifies how AWS engages, scored on content completeness and sales methodology criteria, and gated behind migration.

None of that is a reason to panic and it is not really a technology story. It is the same shift that has happened everywhere else a machine was put in front of a human reader. The written record used to be a description of the work. Now it is the surface the work is judged on, and the gap between what your team knows and what your records say has acquired a price.

Most partner organisations have carried that gap comfortably for years, because a human on the other end filled it in from memory. There is no longer reliably a human on the other end.