Before adding agents, find the system that cannot safely carry the workflow_

A useful AI-readiness review starts before model selection. Research published this week by GFT Technologies and Wakefield Research reports that 84% of surveyed CIOs and CTOs at large enterprises have cancelled at least one AI initiative because legacy systems could not support it. The number is striking, but the engineering lesson is narrower: an AI workflow inherits the weakest operational boundary it depends on.

That does not mean every old application needs to be rewritten. It means the team should trace one valuable business workflow end to end and identify where state becomes ambiguous, integration becomes brittle, permissions cannot be expressed cleanly, or failure cannot be recovered without manual reconstruction.

Map the dependency path before buying more intelligence_

A practical review path is: business outcome → authoritative system → required data → integration boundary → identity and permission → action → post-condition verification → recovery path. The model sits inside that chain. It does not replace it.

For each boundary, record whether the interface is documented, whether reads and writes are idempotent, how freshness is established, how authorization is enforced, what happens on timeout, and how an operator can determine the last known correct state. These are ordinary systems questions, but they determine whether an agent can be trusted with the workflow.

Modernize the blocking boundary, not the entire estate_

If the constraint is a legacy application with no usable API, a narrow adapter may be enough. If the problem is duplicated customer state, establish an authoritative record before adding retrieval. If permissions are inherited through shared credentials, fix identity before allowing autonomous writes. If an action cannot be verified, add a reconciliation step before increasing autonomy.

This creates a more useful modernization backlog because every item is tied to a business workflow and an observable failure mode. It also avoids turning AI adoption into a multi-year replacement programme before the first useful automation ships.

Measure readiness at the workflow level_

Useful measures include percentage of required systems with stable interfaces, unresolved identity gaps, stale or conflicting records, unverified write paths, manual recovery steps, exception rate and time required to reconstruct a failed transaction. A generic maturity score is less useful than knowing exactly why a specific workflow cannot yet run safely.

Parallaxis already works across self-hosted infrastructure, CRM and ERP integrations, durable workflows, browser and application automation, and controlled AI execution. That experience supports the architecture described here; it is not a claim that Parallaxis participated in the GFT study or delivered the outcomes reported by its respondents.

The practical question before an agent pilot is therefore not ‘which model should we use?’ It is ‘which system boundary would make this workflow fail even if the model reasoned correctly?’ Fix that boundary first.