Keep the Behaviour as the Contract

Today's strongest signal: AI can now help untangle old, business-critical systems, but the safe starting point is the behaviour the business cannot afford to lose. Picture a distributor whose pricing engine still runs on code written before its current operations manager joined the company. The code looks dated. The exceptions, rounding rules and customer commitments inside it are not.

This distinction matters because the capability news is moving from drafting toward deeper operational work. OpenAI's new MultiLangBench repository asks models to implement a SQLite-compatible database across programming languages and checks the resulting database against reference outputs. The interesting part for a smaller organization is not the model leaderboard. It is the test design: the output has to behave correctly, not merely look modern.

The same week brought a second signal. Microsoft described business agents as privileged insiders that need identity, permissions and continuous containment. Put the two together and the operating lesson is practical. A model may help a team read old code, map a process or prepare a migration. It still needs a narrow workspace, a measurable contract and a person who owns the release.

The opportunity is substantial. Smaller firms often carry years of rules in spreadsheets, scripts, shared drives and the memories of a few experienced people. AI can help make that knowledge visible and testable. The tradeoff is that a fast rewrite can preserve the obvious screen while changing a quiet business rule. A useful first test is one bounded function with known inputs, known outputs and a rollback path.

Illustrative scenario: A 42-person Ontario parts supplier wants to replace a quoting workbook maintained by one estimator. The team gives an assistant a de-identified copy, ten approved examples and a written list of margin and freight rules. The assistant proposes a replacement formula set, but it cannot publish prices. The estimator runs old and new calculations side by side, records every difference and approves only the cases that match the business rule. The scenario is illustrative, not a reported case.

1. Make observable behaviour the migration contract

What happened. MultiLangBench uses a reference SQLite implementation to check whether a model-produced database changes data exactly as expected. Its public repository describes 24,000 converted tests and a smaller 272-test evaluation subset. This is a vendor-created benchmark, not proof that a model can safely replace a particular production system.

Why a smaller organization should care. Many older systems are difficult to change because the real specification lives in behaviour. A field may be rounded a certain way because of a contract. A missing record may trigger a manual call because someone learned the hard way. AI can accelerate discovery and translation, but a plausible rewrite is not evidence that those rules survived.

The opportunity is to turn examples into a durable acceptance set. Gather routine cases, exceptions, reversals and known past failures. Record the expected output before asking a model to change anything. Run the same cases against the old and proposed systems. This creates a small body of evidence that can outlast the person who currently remembers every exception.

A useful first test this week. Choose one calculation or data transformation that staff already verify manually. Collect 20 de-identified cases, including at least five awkward ones. Define the acceptable result, permitted tolerance and action when a case differs. Let the model explain or rewrite only that bounded step. Keep the current process as the source of truth until the test passes and a named owner accepts the differences.

What remains uncertain. A test set can miss rare conditions, and an old result can itself be wrong. If the system affects payroll, tax, safety, legal rights or a major customer commitment, a small local comparison is not enough. The realistic reason not to proceed is simple: the team may not yet understand the rule well enough to judge a replacement.

2. Give every agent an identity and a smaller action space

What happened. Microsoft argues that an agent combines a model, an orchestration harness, tools, resources and a runtime. Its October 19 security post warns that agents are often overprivileged and proposes continuous monitoring and controls across identity, data, endpoints, networks and runtime. The proposed product approach is Microsoft's; it is not independent proof that an added supervisory agent will catch every failure.

Why a smaller organization should care. A staff member usually has an account, a role and a manager. An assistant connected with a shared administrator token may have none of those boundaries. It can become difficult to answer a basic question after an error: which system acted, under whose authority, on which record and with what evidence?

The opportunity is to make automated work easier to trace than informal manual work. Give each agent or automation a distinct service identity. Limit it to the records and actions required for one workflow. Separate read, prepare, approve and execute. Log the target and result without copying sensitive content into broad telemetry.

A useful first test this week. Inventory one AI-assisted workflow in five columns: identity, data it can read, actions it can propose, actions it can execute and person who can stop it. Remove one permission and confirm the workflow fails closed. Then try a prompt that asks for a higher-privilege action. The refusal needs to come from the tool boundary, not from polite model wording.

What remains uncertain. Continuous security can add cost and operational work. A small firm may not need a new monitoring platform for a read-only assistant. If the workflow handles five low-risk requests a week, a separate account, a short allow-list and manual execution may be enough. More supervisory AI is not automatically the cheapest control.

3. Buy the workflow fit, not the broadest assistant

What happened. Calix announced purpose-built agent workflows for broadband service providers, including role-based controls, governed workflows and a planned no-code studio. The company says its platform draws on more than five billion workflows a year. These are vendor claims and forward-looking product statements, not verified results for every customer.

Why a smaller organization should care. The release illustrates a wider shift from a blank chat box toward software shaped around a job. A service team does not need an assistant that can discuss everything. It may need one that can read a network alert, assemble the approved evidence, recommend a next step and stop before changing a customer's service.

The opportunity is faster adoption because the data, vocabulary and handoffs are closer to the work. The tradeoff is dependence on one vendor's workflow, data model and roadmap. A purpose-built product may also hide important limits behind a polished interface.

A useful first test this week. Ask a vendor to demonstrate one complete case using your terminology and a sanitized example. Include an exception, a permission change and a failed dependency. Request the event record showing what the system read, proposed, skipped and completed. Compare that evidence with the current manual handoff, not with a generic demo.

What remains uncertain. A sector platform may not fit a firm's particular contracts or systems. Integration and change-management costs can outweigh faster setup. A realistic reason not to adopt is that the workflow is already low-volume, reliable and inexpensive. A clear form or checklist may solve the problem without a new agent.

4. Independent evaluation needs enough access to matter

What happened. Anthropic says it has given six METR employees access broadly comparable to its internal risk-assessment teams. The evaluator can publish its analysis, although predefined confidential categories can be redacted. Anthropic also describes three access tiers for other evaluators. This is the company's account of a new arrangement; the useful evidence will be the independent reports that follow.

Why a smaller organization should care. Independence is not a label. An outside reviewer who sees only a prepared demonstration cannot test permissions, failure logs or the cases the vendor finds uncomfortable. The same rule applies to an accountant reviewing an AI-assisted finance process or a consultant assessing a customer-service agent.

The opportunity is a review that improves the system rather than blesses it. Give the reviewer enough access to sample real evidence, reproduce failures and report conclusions in their own words. Protect customer data through scoped test records and clear confidentiality terms. Keep management responsible for the decision.

A useful first test this week. Write a one-page reviewer charter for one planned pilot. State the questions, systems and logs the reviewer can access; what remains excluded; who selects the sample; whether findings may be shared; and who must respond. Ask the reviewer whether those terms are sufficient before the work begins.

What remains uncertain. Deep access can expose intellectual property, personal information or security details. A small vendor may not support a resident evaluator. If meaningful access is impossible, narrow the claim: describe the review as a document check or limited test, not independent assurance of the whole system.

5. Treat vendor governance as continuity evidence, not a guarantee

What happened. Anthropic committed 5% of its shares to a new public-benefit fund, with a possible additional 2% for each 50% increase in company value above a baseline. The company says roughly 20% of its shares will be dedicated to public benefit when earlier pledges are included. Governance details and valuation milestones are still to come, and shareholder approval applies to the initial commitment.

Why a smaller organization should care. A vendor's ownership, incentives and public commitments can affect long-lived dependencies. They may influence investment in safety, worker impacts or nonprofit access. They do not replace a service agreement, an export path or a tested fallback.

The opportunity is better vendor diligence. Ask how the provider funds safety work, handles incidents, changes terms and supports data return. Read governance announcements as evidence about direction. Then convert the parts that matter to your firm into contractual, technical or operational controls.

A useful first test this week. Add four continuity questions to the next renewal: How can we export our data? What happens when a model or feature is retired? Which material policy changes trigger notice? How do we keep the workflow running for 48 hours without the service? Test one export instead of accepting a slide.

What remains uncertain. A fund may do valuable work, but its future decisions are not yet known. Equity percentages do not prove model safety or customer protection. The reason not to make a governance announcement central to a buying decision is that your practical risk may still sit in access, uptime, pricing and portability.

6. Canadian adoption is rising; readiness still decides the return

What happened. Statistics Canada reports that 25.2% of businesses planned to use AI over the next 12 months in the third quarter of 2026, up from 10.6% in 2024. Among those planning AI use, reported plans for large language models rose from 9.3% to 39.3%. The survey used responses from 9,601 businesses or organizations. Plans are not completed projects or measured returns.

The broader evidence adds useful caution. In Ontario, the province says its regulatory-analysis tool scans more than 3,000 statutes, forms and regulations but leaves changes to policy and legal experts. That is a helpful division of labour: machine-scale review, human authority. It also makes a useful distinction between finding a candidate change and authorizing it.

Why a smaller organization should care. Adoption pressure is real, but waiting for a perfect enterprise plan can waste a useful window. The opportunity is one narrow workflow connected to a current business result. The tradeoff is that moving quickly with poor data or unclear permissions can turn a small experiment into a privacy or trust problem. Canada's Privacy Commissioner advises businesses to establish authority for personal-data use, limit sensitive sharing and build privacy into the tool.

A useful first test this week. Pick one recurring queue with a visible owner and a measurable finish, such as preparing service notes or checking required fields. Use sanitized or approved data. Compare five assisted cases with five recent manual cases on elapsed time, corrections, exceptions and accepted outcomes. Keep the write step manual until the evidence supports more authority.

What remains uncertain. National intentions do not predict readiness in one firm, and survey categories combine very different uses. A reason not to adopt now is lack of a stable process, clean data or someone able to own exceptions. In that case, mapping the workflow may create more value than adding a model.

Highest-value moves

1. Turn 20 real cases into an acceptance set before changing a business-critical rule or system.
2. Give each automated workflow its own identity, narrow permissions and a named person who can stop it.
3. Test one complete Canadian SME workflow on results, exceptions, privacy and portability before expanding authority.

Today's strongest thesis

Modernization becomes useful when new capability has to prove it can preserve the behaviour, authority and evidence the business already depends on.