Decentralised News · Agentic Finance · Decision research
By Heath Muchena · Source review 2026-11-11 · Instrument version 1.0.0
What Matters
A platform feature can replace part of an agent product without completing the customer’s whole job. Compare the actual outcome, permissions, delivery work and total cost before declaring either survival or extinction. DN’s assessment records the evidence behind that comparison and the dependencies the business can change. It does not score a moat or predict a platform’s roadmap.
A supplier announces a capability that resembles the feature at the centre of your product. The first reaction may be to build more features or insist that customers value the relationship. Neither response answers whether the buyer can now complete the same job more easily through the platform.
This article examines an existing product’s decision after platform capability expands. It does not rank agent builders or repeat a generic service-arbitrage thesis. The unit is one buyer job, its required outcome and the evidence that would justify renewing the independent product.
DN Evidence Block
Sources reviewed: 2026-11-11 · Evidence type: Primary documentation review and original DN method; examples are explicitly synthetic.
Scope: A requirement-level comparison between an existing product and a specific available platform alternative.
- Microsoft’s declarative-agent guidance explicitly discusses reusing an existing supported experience versus building a new agent and recording dependencies: Microsoft Learn: Declarative agents for Microsoft 365 Copilot.
- Anthropic documents model lifecycle and retirement behaviour, illustrating a separate upstream continuity dependency: Anthropic model deprecations.
- The comparison and scenarios are DN’s decision method, not a claim that any named platform eliminates a business.
Not established by this work: No product displacement, customer switching, competitor benchmark or future platform roadmap was measured.
Original DN instrument · version 1.0.0
DN Platform-Entry Requirement Assessment
Classify requirements for one buyer job against a specific available alternative. Counts do not establish equivalence or competitive strength.
Enter your assumptions or load a labelled example. Required blank numbers stay missing; unknown evidence remains unknown. Use nonpersonal labels only. This instrument makes no network requests and uses no persistent browser storage.
Use your own inputs
No current result. Complete inputs or load an illustrative example.
No live product testing, future roadmap prediction, moat score or recommendation to migrate. Requirements and status are user-entered; criticality is not reduced to a percentage.
1. What complete job does the customer need?
The first question is what the customer needs completed. Write the job from input to accepted outcome. Include preparation, access, action, exception handling, evidence and handoff. Avoid defining the job so narrowly that the existing product wins by construction.
Classify each requirement as critical or optional before comparing alternatives. A critical condition should describe why the buyer cannot accept the outcome without it. This prevents the seller from reclassifying a newly matched feature as unimportant or inventing a trivial condition solely to preserve a differentiation story. The buyer’s actual acceptance boundary, supported by evidence, should govern the comparison.
2. Which required steps does the available feature cover?
Microsoft’s declarative-agent guidance says an existing supported experience or approved agent may already meet the need and calls for checking dependencies. That is a useful primary-source example of a build-or-reuse boundary. It does not show that every independent product is redundant or that every tenant has the same capabilities and permissions.
Test the available feature under the buyer’s actual conditions where authorized. A demo with sample data can establish that an interaction exists; it cannot establish that the customer’s production task is completed. Record unsupported requirements and unknowns separately. “The platform probably adds this next quarter” is a scenario assumption, not current coverage evidence.
3. What delivery and exception work remains?
The third question asks what work remains. A built-in capability may reduce the model or interface work while leaving integration, permission setup, quality review and support. Those remaining tasks can support a business only if customers value them and the provider can deliver them economically.
For a synthetic example, consider a report service with five requirements: retrieve approved records, resolve inconsistent identifiers, draft an explanation, obtain review and deliver an auditable result. A platform that now drafts the explanation covers one capability. The comparison must determine whether its wider supported environment can also complete the other steps, rather than assuming either answer from the announcement.
4. Who will perform the remaining work?
Do not call every inconvenience a defensible advantage. If the buyer can remove it with a small configuration change, it may not sustain a recurring product fee. Conversely, a controlled workflow with a documented acceptance record may remain valuable even when the underlying text generation becomes widely available. The claim needs customer and task evidence.
Consider whether the remaining service is a recurring product or a one-time implementation. A platform may absorb the recurring interface while leaving a temporary migration opportunity. That can still be valuable paid work, but its economics and renewal story differ. Price the service the buyer now needs rather than preserving the old subscription label after the underlying job has changed.
5. What does the complete alternative cost the buyer?
The fifth question is the buyer’s total cost over a stated period. Compare licensing or usage charges, setup, operator time, review, support and migration under the same accepted outcome. An already purchased platform entitlement can reduce incremental cost, but an included feature is not automatically zero-cost to deploy and operate.
Use a transparent synthetic comparison. Suppose the independent service costs 600 CU per month and requires two hours of buyer supervision. The platform route has 200 CU of incremental usage and requires eight hours of buyer work. At an entered 50 CU per hour, recurring totals are 700 and 600 CU respectively, before migration and differences in outcomes. These are illustrative assumptions, not vendor prices or measured effort.
If the platform route also requires 1,800 CU of one-off setup, the 100 CU monthly difference would take 18 months to recover under unchanged assumptions. If the buyer’s required outcome is not met, that break-even is not yet a valid replacement comparison. First establish equivalence; then calculate cost. An attractive arithmetic result cannot compensate for a missing critical requirement.
Inspect sensitivity rather than defending a preferred answer. At four hours of platform-side work, the recurring alternative becomes 400 CU and the same setup is recovered in six months. At ten hours, recurring cost reaches 700 CU and there is no recurring saving to recover setup. The practical research question is which effort estimate the buyer can actually support.
6. Which distribution access does the product depend on?
The sixth question concerns distribution access. Identify whether the product reaches buyers through a platform-controlled listing, interface or integration. Record the part of the customer relationship supported by that route and the actual conditions under which access can change.
A backup model does not by itself solve a distribution dependency. A mailing list does not by itself solve a broken integration. Map each dependency to the customer job it supports and test the relevant transition. Keep actual export rights and usable formats separate from a reassuring statement that data is portable.
7. Which operations and records can move?
The seventh question concerns operational portability. Identify which permitted records, workflows and support capabilities can continue if the platform route changes. Map each dependency to the customer job it supports and test the relevant transition. Keep actual export rights and usable formats separate from a reassuring statement that data is portable.
Anthropic’s model-deprecation documentation distinguishes active, deprecated and retired models and explains that retired-model requests fail. This is a continuity example, not evidence of product competition. It shows why an upstream feature or lifecycle change needs an owner, a detection route and a tested response while customer commitments continue.
8. What evidence earns the next renewal or build?
The eighth question is the decision rule. Ask a current or prospective buyer to compare complete supported outcomes under clear terms. Record why they would retain the product, move to the platform, purchase a narrower service or stop the task. Do not treat a friendly statement of loyalty as a renewal commitment.
Possible responses include concentrating on a valuable remaining job, integrating with the platform, changing packaging, reducing a redundant scope or retiring an offering. The right response depends on observed buyer value and delivery economics. Adding a feature solely because the platform added one can increase maintenance without improving the purchase decision.
Keep an evidence register with requirement, current-product result, platform result, source or test, unresolved owner and next review trigger. The local tool summarizes counts only; it does not weight the requirements or proclaim a competitive advantage. A single unmet critical condition can matter more than several convenient features, so retain criticality in the underlying record.
A product is worth maintaining when its complete promise continues to earn a buyer’s commitment at a sustainable cost. That conclusion needs updating as capabilities and customer needs change. The defensible asset is the supported relationship between a real job, checked outcomes and a viable service, rather than a claim that one feature can never become ordinary.
Set a re-review trigger tied to a material event: a supported capability release, changed licensing, a buyer renewal or a failed migration test. Constantly reacting to speculative roadmaps can consume the same resources as unnecessary feature building. The maintained assessment should distinguish current substitution evidence from a future scenario and state which event would justify spending time on that scenario again.
Methodology, limitations and corrections
Define the complete buyer job and critical requirements before reviewing the announcement. Verify the feature’s actual availability, scope, permissions and applicable commercial context. Compare accepted outcomes and total buyer effort on permitted cases, keeping current evidence separate from roadmap assumptions.
The cost example is synthetic. Its recovery period assumes equivalent outcomes and a stable recurring saving; when either is unsupported, the comparison remains unresolved. Review dependency changes separately from competitive substitution. A record of unmet requirements is a research agenda, not proof that the independent business has a durable advantage.
For corrections, identify the claim, source and date when contacting Decentralised News. A new record-creation timestamp does not refresh its underlying evidence.
Change log: version1.0.0, 2026-11-11. Initial documentation review, original instrument and labelled examples.
Frequently asked questions
Does a platform feature automatically erase a product?
No. Compare the complete job, supported conditions and economics. Similar demonstrations can hide different obligations.
Is customer loyalty enough evidence?
It is useful feedback, but renewal or a clearly scoped paid commitment provides different evidence. Record the distinction.
Why does the tool avoid a moat score?
Requirement counts cannot capture criticality, evidence quality or future competition without unsupported weights.
Should an independent service integrate with the platform?
That is one option to evaluate. Confirm the supported route, rights, costs and customer benefit before treating it as the answer.
Primary sources
- Microsoft Learn: Declarative agents for Microsoft 365 Copilot. Microsoft describes when to reuse an existing approved agent or build a distinct experience, and requires explicit outcome, capabilities, permissions, licensing and support dependencies. It does not establish that a third-party business has been displaced. Reviewed 2026-11-11.
- Anthropic model deprecations. Model lifecycle changes and notice periods affect continuity; verify current schedule before relying on a date. Reviewed 2026-11-11.
Turn the finding into a decision
The DN Research Desk can scope a requirement-level platform-alternative and buyer-cost comparison, subject to source access and a written quote. Start with one unresolved decision and the records available to answer it. This article does not promise a completed audit, integration or independently verified result.
Related DN research
Disclosure: Analysis and instrument results are editorial. Where labelled affiliate links appear, DN may receive compensation when you sign up or buy through them. Commercial relationships do not determine findings. No tested integration or guaranteed outcome is implied.
