3 Things AI: The “Real Work Has Consequences” Edition

1. Passing half the checklist is not closing the books

A new accounting benchmark built by Mercor with Ramp tested nine frontier models on 160 expert-authored tasks across ten synthetic companies. The work included reconciliation, data entry, variance analysis, schedules, and accruals, with access to accounting software, spreadsheets, PDFs, email, and other files. The leading model met 56.4% of the rubric criteria across three attempts, but no model fully passed more than 2.6% of tasks across eight attempts. The strongest eight-attempt pass rate was 21.5%. This is a preprint and a closed benchmark based on U.S. accounting rules, so it is evidence about the evaluated systems, not a verdict on every accounting workflow.

The gap between partial criteria and a completed deliverable matters. An agent can find the right invoices, calculate most entries, and format a tidy workbook while still missing one exception that prevents the close from being correct. More token budget improved aggregate scores, but the paper also found that spending more tokens within a fixed budget did not reliably indicate a better result. The model can look extremely busy while the suspense account remains unimpressed.

For a Canadian SME, the decision is not whether AI can “do accounting.” It is which bounded step it can complete under the organization’s chart of accounts, tax treatment, approval rules, source documents, and review threshold. Drafting a variance explanation may be a useful read-only assist. Posting an entry or changing a vendor record has a different consequence and needs a different gate.

IntelliSync perspective: evaluate the completed accounting outcome, not the fluency of the intermediate work. A system that satisfies many criteria but fails the final acceptance test is an assistant awaiting review, not an autonomous process.

Practical takeaway: build a ten-case evaluation pack from sanitized historical work. Include routine and exception cases, define pass criteria with the controller or bookkeeper, record every source document used, and separate read-only analysis from posting authority. Measure full-task pass rate, correction time, and unreconciled differences before expanding access.

2. The AI teammate may be taking up the whole meeting

A randomized study placed 80 undergraduates into 33 teams for an 18-minute, text-based rescue decision. Sixteen teams had two students and an AI teammate; 17 had three students. In every mixed team, the AI was the most talkative and self-referential participant, yet its contributions carried the least new information and the lowest density. The researchers also observed lower human-to-human responsiveness, social impact, belonging, and perceived status in the AI-assisted teams. Greater AI dominance was associated with participants feeling less valued.

The limits are important. This was one small preprint using one persona, one model configuration, one moral scenario, and one text session. It does not prove that every workplace assistant weakens every team. It does show that adding an articulate participant changes the communication system even when management intended to add only a tool.

That distinction matters in planning, sales review, hiring calibration, incident response, and other SME meetings where the discussion creates shared judgment. If the AI speaks first, summarizes too often, or answers every pause, people may respond to the machine instead of developing each other’s ideas. A cleaner transcript is not automatically a stronger team. Sometimes the meeting needed a second human thought, not a paragraph generated before anyone finished inhaling.

IntelliSync perspective: collaboration quality is an operating metric. AI participation should improve the team’s evidence, options, and decisions without quietly reducing human contribution, challenge, or ownership.

Practical takeaway: assign the AI a bounded meeting role. Let humans state initial views before it contributes; use it to retrieve evidence, identify missing assumptions, or summarize after deliberation. For four weeks, track speaking balance, distinct human ideas, challenges raised, decisions changed by evidence, and whether participants can explain the final rationale without consulting the transcript.

3. Agent memory needs an expiry date and a repair path

Persistent memory helps an agent carry preferences and project context across sessions. It can also preserve a malicious instruction long after the original document or conversation has disappeared from view. MemSecBench tested 310 cases across 48 code, science, daily-life, and office contexts using 24 combinations of agent harnesses, memory backends, and models. Across those configurations, malicious memory persisted in 84.2% of cases and the full write-to-consequence chain succeeded in 50.3%. Among successfully poisoned cases, selective repair preserved required benign memory only 56.1% of the time.

These are benchmark results in isolated runtimes, not observed loss rates in deployed businesses. They still expose a practical blind spot. Many teams govern what an agent can do today but not what it is allowed to remember for next month. A temporary supplier instruction, exception rule, or copied preference can lose its date, owner, or original warning as it is compressed into memory. Later, the system may treat stale or hostile context as standing policy.

Deleting everything is not a mature repair strategy. The agent may need to forget the poisoned rule while retaining the valid supplier record, project preference, or customer constraint beside it. That requires provenance and selective invalidation, not a cheerful “memory cleared” notification.

IntelliSync perspective: memory is a governed data store, not a personality feature. Every durable item needs a source, scope, owner, freshness rule, sensitivity class, and revocation path before it can influence an action.

Practical takeaway: inventory one agent’s memory path from write to recall to action. Block untrusted content from becoming policy, attach source and expiry metadata, require approval for durable rules, and test a poison-recall-repair scenario. Verify both that the bad instruction no longer affects behaviour and that legitimate context still works.

The bigger pattern

AI is moving from impressive answers into accounting systems, team conversations, and organizational memory. That shift changes what good evaluation looks like. Model quality still matters, but it is only one layer.

Leaders need proof that the work closes, the team still thinks, and the context remains trustworthy. Those are workflow, organizational, and security outcomes. None can be established by a polished demo or a usage dashboard.

Test the completed task. Design the human role. Govern the memory lifecycle. Real work has consequences, and useful AI architecture makes those consequences visible before they arrive in production.