DEV Community: Mikhail Savchenko

AI Visibility for Operators, Measured on Our Own Site

Mikhail Savchenko — Mon, 31 Aug 2026 05:38:47 +0000

Our own numbers, since they make the point better

An AI visibility audit of inite.ai returns 90 out of 100 for readiness and 25 out of 100 for visibility.

That means the crawlers can parse everything we publish and the engines still rarely mention us. Two of six engines recall the brand when handed the name. Zero of six recommend us in category, which is the question a buyer actually asks.

Search Console tells the same story from the other side: 30 clicks and 3,262 impressions across a month, and zero impressions against any commercial query. Not low positions. Absence.

We are publishing this because the alternative is writing about AI visibility from behind a number we have not earned, and because the gap itself is the useful thing to understand.

Readiness is cheap. Visibility is not.

	AI readiness	AI visibility
What it measures	Whether an engine can read you	Whether it chooses to mention you
Who fixes it	A developer, in a fortnight	Evidence accumulated over months
Improves	Immediately	Slowly, if at all
Cost	Low and one-off	Ongoing
What it is worth alone	Nothing	The whole thing

The two get priced as if they were the same product. A vendor who sells visibility and delivers readiness has delivered something real, much cheaper than what you thought you bought, and you will not notice for a quarter because the readiness score moves immediately.

The number to watch

Category recommendation, not brand recall.

Brand recall asks whether an engine knows you exist once your name is supplied. It is easy to improve and worth very little, because someone who already knows your name has other ways to reach you.

Category recommendation asks whether you appear when somebody describes a problem and asks who solves it. That is the question a buyer types. Our own split of 2 of 6 against 0 of 6 is the difference between being findable and being recommended, and only the second has revenue attached.

Ask any vendor which of those two their headline number describes. The answer is informative.

What actually seems to move it

Nothing exotic, and nothing that can be finished in a fortnight.

Answer a specific question completely, on a page that is about that question, in the form the question is asked. Mark it up so the answer is extractable rather than buried in a narrative. Then get corroborated somewhere that is not your own domain, because an engine weighing whether to recommend a vendor is looking for something that is not the vendor's own claim about itself.

What does not appear to move it is the thing most commonly sold. llms.txt appeared on 10.13% of domains and SE Ranking's November 2025 study across 300,000 domains could not detect a citation lift attributable to it. We publish one anyway because it is inexpensive to maintain. That is a much weaker claim than the one usually made for it, and the full argument is here.

Why bother, when 93% of AI Mode is zero-click

Because the traffic is not the asset.

In a zero-click answer the assistant states a conclusion and names sources. Being one of those names puts you in the shortlist a buyer carries into their next conversation, including the one where they eventually type your name directly.

Treating it as a traffic channel produces the wrong measurement and then the wrong conclusion, which is almost always that it did not work. Count whether you are named in answers to the questions your buyers ask, and watch branded search over the following months. If your reporting counts only sessions, a successful programme and a failed one look identical.

What an operator should do about it

Three things, in order, and none of them is buying a tool.

Find out what an assistant currently says when asked who does what you do in your city or sector. That takes an afternoon and it is the only baseline that matters.

Fix readiness once, because it is cheap and because being unreadable makes everything after it pointless. Whether you let the crawlers in at all is a business decision rather than a technical one, and the allowlist post sets out the trade.

Then spend the ongoing effort on evidence rather than markup: cases with numbers, answers to real questions, and corroboration on domains you do not own. That is slow, and it is the part that separates the two scores. The mechanics, with the schema that matters and the part that does not, are in the AEO guide.

The honest summary

We are good at the cheap half and bad at the expensive half, and we can prove both with numbers.

Anyone selling you the cheap half at the price of the expensive one will show you a score that improves in week two. Ask what it measured.

Why Your Last Chatbot Failed, and It Was Not the Model

Mikhail Savchenko — Mon, 31 Aug 2026 05:38:47 +0000

The metric caused the experience

Most chatbot dashboards lead with deflection rate: the share of conversations that ended without a human.

Read that definition again from the customer's side. Every handover counts as a failure. Every refusal to hand over counts as a win. A customer who gave up and closed the window scores identically to a customer who was helped.

A system optimised against that number learns to keep people circling through restated questions and suggested articles. This is not a subtle misalignment. It is the precise mechanism behind the experience people are describing when they say they hate chatbots, and it was designed in on purpose, by whoever chose the metric.

Three other things that were probably true

What went wrong	What it looked like to the customer	Fixable by
Scoped to answer everything	Confident wrong answers on edge cases	Defining what it may answer
No access to your systems	Paraphrasing the FAQ page	A read path into orders, stock, billing, calendar
Nobody read the transcripts	The same failure every week for a year	One person, one hour, weekly

The second is the one that quietly determines everything. A support automation connected to nothing can only restate published content, so it competes with your own search box and loses, because the customer read that page before opening the chat.

The questions that generate contacts are specific and personal. Where is my order. Is this still available. Why was I charged this. Can I move my appointment. Answering any of them needs a read path into a real system, and building that path is most of the actual work.

A proposal that skips it is quoting for a wrapper around a knowledge base. The demo will look excellent, because demos ask general questions.

What a working version does differently

It answers only what it can verify, and it says where the answer came from.

In a brokerage deployment we ran, the automation answered what the listing itself could answer: floor, area, price, what is included, whether the property is still available. Everything else went to a named agent with the conversation attached. Response time went from 6 hours to 8 minutes, and the reason it worked is that the automation never guessed.

Anything binding goes to a person by design. Pricing outside the published rate, terms, commitments. That boundary is the subject of our rules for keeping a person in the loop, and it is not a limitation we apologise for: an automation that agrees something on your behalf at 2am is a liability rather than a feature.

Handover is the whole product

Three things go wrong here and all three are cheap to fix.

The escape hatch is hidden, so the customer has to guess a magic phrase to reach a person. Say in the first message that a human is available.

The handover arrives as a bare alert, so the agent opens by asking what the customer has already explained twice. Carry the transcript across, or the automation has cost time rather than saved it.

The queue behind the handover is not staffed for what the bot escalates, so a fast refusal becomes a long silence. That is a capacity decision, and it has to be made before launch rather than discovered in week two.

Route on the first sign of frustration, not the third. The cost of an unnecessary handover is a few minutes of an agent's time. The cost of a refused one is the customer.

When we say do not build it

More often in this category than in any other, and usually for one of three reasons.

The contacts are mostly things a bot cannot verify. The volume is too low for anyone to maintain it. Or the real problem is that human response is slow, and support automation would be a decoration over that.

The third case deserves naming because it is common. If enquiries wait four hours because nobody is there at seven in the evening, a bot that says something friendly and unhelpful at seven in the evening has not fixed the wait, it has automated it. The money is better spent on routing, on coverage, or on removing the reason people are contacting you at all.

That is the same test as the fifth readiness condition: if the bottleneck is not here, making this part faster changes nothing anyone can bank.

What to ask the next vendor

Which systems will it read from, and what will it do when that read fails.

What is it measured on, and if the answer is deflection rate, what happens to the number when it hands over correctly.

How does a customer reach a person, in how many messages, and who is waiting when they arrive.

And ask to see a transcript from a real deployment on a bad day. The order-processing split between rules and model is what a defensible answer to the first question looks like: deterministic questions answered by rules, unstructured input read by a model, and the two never swapped.

n8n Says Static Role Permissions Don't Work for Autonomous AI Agents

Mikhail Savchenko — Sun, 30 Aug 2026 17:48:59 +0000

n8n published an engineering post arguing that role-based access control, the standard permission model for human users and most software integrations, does not hold up once AI agents are given autonomy to chain actions across multiple systems.

The core problem the post describes: a static role grants a fixed set of permissions regardless of what the agent is currently doing. A human support rep with 'edit ticket' access uses that permission consistently and predictably. An AI agent with the same role might use it to update a ticket, but it might also use the same standing permission to trigger a refund, modify a customer record, or forward data to an external tool — actions the role was never scoped to authorize for that specific task. Because agents interpret instructions and chain tool calls dynamically, a role that looks safe in isolation can be exploited or misapplied in ways a static permission list cannot anticipate.

n8n's proposed alternative centers on scoping access to the task rather than the identity. Instead of granting an agent a persistent role with broad standing permissions, the model grants narrow, short-lived access tied to the specific workflow step being executed — sometimes described as just-in-time or attribute-based access control. Under this approach, an agent processing a refund request would receive a scoped credential valid only for that transaction type, for a limited time window, rather than a standing 'finance-write' role it can invoke at any point in any workflow.

The post also raises the audit implication: static RBAC produces logs that show which role acted, but not which task justified the action. Dynamic, task-scoped permissioning ties every access grant to a specific workflow execution, making it possible to reconstruct why an agent had access to a given system at a given moment — a capability that matters both for security incident response and for compliance reviews where a company must demonstrate that AI systems only touched data relevant to their assigned task.

This is not a product announcement or a regulatory change; it is an architectural argument from a workflow automation vendor whose customers are actively building agent-driven automation. No specific tooling, deadline or enforcement mechanism accompanies it. Companies already running AI agents against production systems — CRMs, ticketing platforms, billing, internal databases — are the direct audience: the recommendation to move from standing roles to scoped, auditable, task-level permissions applies to any automation stack where an agent's tool access is currently provisioned as a single broad role rather than reviewed per workflow.

When the Integration Changes Underneath You

Mikhail Savchenko — Sun, 30 Aug 2026 15:19:43 +0000

The failure that does not announce itself

An automation that stops is a small problem. It stops, somebody notices within the hour, the cause is obvious because the last thing that changed is the thing that broke.

The expensive failure is the one that keeps running. A field is renamed upstream, the code that reads it gets nothing, and nothing is a legal value in most processes - an empty note, an unset flag, a missing second line of an address. Nothing raises. The workflow produces records that look exactly like last week's records, and it does that for as long as it takes somebody to compare two numbers by hand.

What actually changes

Four shapes account for most of it.

A field is renamed or moved, usually as part of a tidy-up nobody thought was external. A payload gains a level of nesting when a vendor adds a wrapper for pagination or metadata. An enum gains a value - a new order status, a new document type - and the branch that handles the known values silently drops the unknown one. An API version sunsets, and the fallback turns out to be an older shape rather than an error.

None of these are outages. Every one of them is a Tuesday afternoon in somebody else's release notes.

Three defences, all cheap

One record, end to end, every morning. A synthetic item that goes the whole way and is checked at the far end against a known answer. It exercises the joins between systems, and the joins are where drift lives. Four separately healthy services can still be handing each other something that changed.

Assert on shape, not on status. A two hundred with a parseable body is not evidence that the body means what it meant last month. Check that the fields you read are present and typed as expected, and fail loudly when they are not. This is ten lines and it converts a silent wrong answer into a visible stop.

Alert on distribution, not on exceptions. If one in twenty items took the manual path last month and one in six takes it today, that is the signal - and no exception was raised to produce it. This only works if the ordinary numbers were written down first, which is the argument a measured baseline makes for itself.

Why this is a scoping question, not a maintenance one

Every integration is a dependency on somebody else's release schedule. That does not make it a bad idea; the rental delivery in where the four hours go reads availability from a system we do not control, and it still pays for itself. It makes the dependency a thing to price.

The practical version: when a workflow is scoped, list what it reads from outside itself, and for each one say what happens if the shape changes. Most answers will be "it stops, and that is fine". The ones where the answer is "it keeps going and we would not know" are the ones that need a canary before they ship, not after the first bad month.

The part nobody wants to name

A workflow that no person is responsible for is a workflow being checked by whoever happens to look, which in practice means after a customer complains. The name goes in the handover document with everything else, and it belongs to somebody who has opinions about the design rather than to whoever was free that week. The argument for treating that as a stage rather than an afternoon is in what a process audit must actually produce, and the reason it cannot be added later is that the person who forgot what was confusing cannot write it down.

How to Read an Automation Quote Before You Sign It

Mikhail Savchenko — Sun, 30 Aug 2026 15:19:42 +0000

Read the shape before the number

Most quote reviews start at the total and work backwards, which is the wrong order. The total is a conclusion. The structure is the evidence.

A quote is a description of scope wearing a price, and the first thing to check is whether the scope is defined by the process being automated or by a list of deliverables that could describe almost anything.

"AI integration, discovery, implementation, testing, deployment" describes every project ever quoted. "Booking intake across four channels, availability resolved against asset state, agreement generated from your approved template, dispatch scheduled" describes one.

What should be on the page

Line	Why it matters
Measurement or discovery, priced separately	A quote without one is a guess about an uncounted process
Build, tied to a named process	Not to a technology, which could mean anything
Integration, per system	Estimates go wrong here, and one combined figure hides which system is the risk
Monthly running cost	The most commonly absent line, and the one that decides payback
Handover, and what documentation exists	Decides whether you own the result or rent it
Support terms, with a response time	Otherwise "we'll be around" is the whole commitment

Any of these missing is a question rather than a deal-breaker. All six present means the quote can be compared to another quote with all six, which is the only way a price comparison means anything.

What a single-line total hides

Which assumptions can move.

Automation costs are dominated by volume and by integration surface, and at quoting time both are estimates. Itemised, you can ask what happens at half the assumed volume, or what the price becomes if the fourth system needs a different approach. The answers show you where the risk sits.

Collapsed into one number, every later change becomes a renegotiation from a position where you cannot tell which part moved.

Single-line quotes are more often lazy than dishonest. The effect on you is the same either way, and asking for a breakdown costs nothing and is refused surprisingly often.

The four costs that go missing

Model and infrastructure spend per decision, which at real volume is a monthly line rather than a rounding error.

The time of whoever handles escalated exceptions. This is a designed cost, not a defect, and it needs an honest escalation-rate estimate rather than an assumption of nearly zero.

Maintenance when the world moves. A supplier changes a form, a channel changes an interface, and somebody has to notice and fix it.

The process owner's continuing time after handover, because an automation nobody owns degrades quietly while the dashboards keep looking fine.

Ask for all four as one monthly figure, add twelve of them to the build price, and compare those totals. The four questions that break most ROI numbers then have something to work on, because payback at three to six months cannot be checked at all without a monthly cost.

Two structural things worth checking

The payment schedule. If every milestone is a date rather than a working thing, you are funding elapsed time. At least one payment should be tied to something running in production that you can look at.

The timeline against the scope. We put one to three workflows into production in two to four weeks, so a quote for a single workflow measured in months is describing different work — possibly a replacement project, possibly a discovery exercise with a build attached. Neither is wrong, but you should know which one you are buying.

The best question to ask

What am I not getting for this.

A good vendor answers immediately and specifically, because they have already decided what is out of scope: the edge cases that stay manual, the system not integrated in this phase, the report not included. Ours should tell you which parts stay with a person by design, since that boundary is deliberate rather than a limitation.

A vendor who cannot answer has either not thought about scope or is postponing the conversation until it becomes a change request. Both produce the same argument in month three.

Before any of this arrives

The quote is easier to read when you already know the answers. Count your own volume from your own systems, name the owner, and know which of your systems is authoritative for each disputed field.

That is the same preparation described in what makes a process map worth having, and it converts a quote review from an exercise in trust into an exercise in arithmetic. If the numbers in the quote disagree with yours, you have a specific conversation rather than a general unease.

And if the readiness conditions in when not to automate yet are not met, the best-written quote in the world is still a quote for the wrong project.

OpenAI Says AI Defenders Have a Closing Head Start Over Attackers

Mikhail Savchenko — Sun, 30 Aug 2026 01:28:04 +0000

OpenAI's essay The Defender's Window makes the case that artificial intelligence, in its current state, disproportionately benefits the defensive side of cybersecurity — the analysts, engineers and automated systems trying to detect and stop intrusions — rather than the attackers trying to breach them. The argument rests on the idea that AI is especially good at pattern recognition, anomaly detection, and rapid triage at scale, tasks that map closely onto defensive security work such as log analysis, phishing detection and vulnerability scanning.

The piece frames this as a 'window' rather than a permanent state. OpenAI argues that attackers will eventually adopt the same AI capabilities to automate reconnaissance, generate more convincing phishing content, and probe systems faster than before. Once that happens, the current defensive advantage narrows or disappears. The implicit call to action, per OpenAI's framing, is for organizations and policymakers to invest in AI-driven defense now, while the asymmetry still favors the defenders.

Specifics of what OpenAI itself is doing operationally — whether this includes new detection tooling, threat-intelligence sharing, or product features — are not detailed in the summary available and should be treated as unconfirmed pending the full text of the essay.

For operators running sales, support or operations at a 10-200 person B2B company, the essay's core claim has a direct, near-term implication even without new OpenAI products attached to it. Most of these companies already run support desks, billing systems and vendor communications through channels that are frequent targets for AI-assisted phishing and business email compromise. If defenders genuinely hold a temporary AI-driven advantage, the actionable step is to use that advantage inside existing workflows: layering AI-based anomaly detection onto support ticket queues, flagging unusual invoice or payment-change requests automatically, and using AI to spot deviations in vendor or customer communication patterns that a human reviewer might miss under normal ticket volume.

This is not a call to buy a new dedicated security platform. Many of these companies already use AI copilots or automation platforms for support and ops; the marginal step is extending that same automation to flag security-relevant anomalies rather than treating fraud detection as a separate, unaddressed function. Once attackers catch up — using AI to generate more convincing phishing emails or fabricate more believable vendor requests, a trend already visible in less sophisticated forms — the companies that built these checks into existing workflows early will have a real head start over those that treated it as someone else's problem.

The essay does not specify a timeline for when this defender's advantage might close, and OpenAI does not commit to concrete product changes in the portion summarized here. Readers should treat the broader claim as a policy argument rather than a technical guarantee, and watch for follow-up detail on what OpenAI or other vendors ship to operationalize it.

FTC Enforcement Action Targets False AI Marketing Capability Claims

Mikhail Savchenko — Sat, 29 Aug 2026 04:17:51 +0000

The FTC announced it has finalized orders with Cox Media Group and two other firms, resolving charges that the companies deceived customers about an "active listening" AI-powered marketing service. The FTC alleged the firms marketed a service claiming it could use smartphone microphones and other devices to listen to consumers' conversations and use that data to serve hyper-targeted advertising — a capability the agency says the companies could not substantiate.

The finalized orders bar the companies from making similar unsubstantiated claims going forward and require them to have competent evidence supporting any future advertising-technology capability claims made to customers or the public.

This is not a case about a data breach or unauthorized surveillance being confirmed — the FTC's action centers on deceptive marketing, meaning the agency found the companies advertised a capability that either did not exist as described or could not be proven to exist, and sold that claim to advertisers and agencies as a differentiator.

For B2B operators, the case matters less because of what Cox Media Group did and more because of what it signals about enforcement direction. As more sales, support and marketing tools ship with AI-branded features — sentiment analysis, predictive lead scoring, automated call summarization, intent detection — the gap between marketed capability and actual technical function is becoming a regulatory target. Companies procuring these tools for sales or support automation should treat vendor AI claims the way they'd treat any other technical spec: verifiable, not aspirational.

Practically, this means procurement and legal teams evaluating AI-enabled sales or support software should ask vendors for technical documentation, not just marketing copy, when a tool claims to detect intent, sentiment, or behavioral signals. It also means companies marketing their own AI-enabled offerings — including consultancies and software vendors serving other businesses — need to ensure that public-facing claims about what an AI feature does are backed by testable evidence, since the FTC has shown willingness to act on deceptive AI marketing even in B2B advertising-technology contexts rather than only direct-to-consumer products.

The orders do not, as of this report, specify monetary penalties beyond the compliance and reporting requirements typical of FTC settlement orders; any financial terms should be confirmed against the full order text once published. Companies with existing marketing or ad-tech vendor relationships involving AI-driven targeting claims should treat this as a prompt to request substantiation documentation from those vendors now, rather than waiting for a similar enforcement action to surface in their own supply chain.

Claude Now Embeds Detectable Watermarks in Generated Text

Mikhail Savchenko — Sat, 29 Aug 2026 03:49:17 +0000

TechCrunch reports that Anthropic has released additional technical detail on a watermarking system built into Claude's text-generation models. The mechanism embeds a statistical signal into generated text that can later be checked by a detector to confirm whether a given passage came from Claude, without requiring changes to the visible wording or meaning of the output.

The stated goal is to give platforms, publishers, and researchers a reliable way to trace AI-generated text back to Claude, addressing concerns around plagiarism, disinformation, and academic misuse. Anthropic joins Google and OpenAI, both of which have shipped comparable watermarking or provenance systems for their own models, in treating detectable provenance as a standard model feature rather than an optional add-on.

What remains unconfirmed at this stage is how robust the watermark is against common downstream transformations — paraphrasing, translation, reformatting, or merging AI text with human-written text — and whether Anthropic will expose a public detector API or restrict verification to trusted partners. TechCrunch's report does not specify pricing, rollout timeline across Claude's model tiers, or whether watermarking can be disabled for enterprise API customers with specific compliance needs.

For B2B companies in the 10-200 person range, the practical exposure is narrower than it sounds but still real. Any workflow where Claude drafts material that later reaches an external audience — sales outreach, contract language, support macros, marketing copy — now carries a traceable signal of AI origin, assuming the watermark ships broadly and survives normal editing. That matters most in contexts where AI-generated content triggers a policy: some procurement processes, RFP responses, and regulated-industry communications already require disclosure of AI assistance, and a few explicitly prohibit undisclosed AI-drafted submissions.

Operators should treat this as a prompt to review, not panic. Start by identifying which customer-facing outputs run through Claude with little to no human rewriting, since those are the pieces most likely to retain a detectable signal. Check existing client contracts and RFP requirements for AI-disclosure clauses that may now be enforceable in practice rather than theoretical. Where disclosure is required, build it into templates now rather than reacting to a client-side detection event later. Where Claude output is heavily edited or blended with human writing before it goes out, the practical risk is lower, but teams should not assume the watermark disappears without testing.

Anthropic has not indicated any pricing or API changes tied to this feature, so there is no cost impact to budget for yet. The operational impact is entirely about content provenance and disclosure obligations, not model capability or spend.

AWS Shows How to Build Multi-Step AI Agents Without Custom Orchestration Code

Mikhail Savchenko — Thu, 27 Aug 2026 18:15:23 +0000

AWS's Machine Learning Blog published a guide detailing how to build agentic AI workflows by combining Amazon SageMaker AI with Bedrock AgentCore. The post lays out a reference pattern for teams that need agents to do more than answer a single question — agents that plan multi-step tasks, call external tools, retain memory across a session, and hand off between specialized sub-agents.

SageMaker AI in this pairing handles the model side: training, fine-tuning, and hosting custom or open-weight models where a company needs more control than a hosted foundation model API provides. Bedrock AgentCore supplies the agent runtime layer — session memory, identity and access boundaries, and orchestration for invoking tools or other agents mid-task. Together they form a stack where a company doesn't need to build its own state management, tool-calling framework, or agent-to-agent handoff logic from scratch.

This is an infrastructure story more than a model story: nothing here is a new model capability. What's changed is the availability of a managed, documented path for assembling multi-step agents on AWS, with AgentCore handling the plumbing that most teams previously had to write themselves — session persistence, credential scoping per agent, and structured tool invocation.

For B2B companies in the 10-200 employee range, the direct relevance isn't that internal engineering teams should start wiring SageMaker and AgentCore together. Few companies that size have the SageMaker MLOps expertise or the volume to justify custom model hosting. The relevance is upstream of that: this is the kind of building block that automation vendors and consultancies — including the tools your sales, support and ops teams already touch — are increasingly assembling on top of. When a vendor claims their support bot can look up an order, escalate to a human, and remember the last three exchanges in a session, this is roughly the kind of managed infrastructure making that reliable at reasonable cost, rather than a fragile custom script.

The practical use is diligence. When evaluating an AI agent for lead qualification, ticket triage, or order processing, operators should ask what runtime the agent uses for memory and tool access, whether sessions are isolated per customer or per case, and how access is scoped when the agent calls out to a CRM or billing system. Answers grounded in managed infrastructure like AgentCore (or an equivalent from another cloud provider) suggest a more auditable, maintainable setup than a bespoke prompt-chaining script — one that's more likely to survive a vendor's own team turnover or a scaling event.

Unconfirmed: pricing details for combined SageMaker AI and Bedrock AgentCore usage were not fully broken out in the source post, and should be checked directly against current AWS pricing before any cost comparison is made.

OpenAI Data Shows Enterprise AI Moving From Chat to Task Execution

Mikhail Savchenko — Thu, 27 Aug 2026 14:26:07 +0000

Enterprises are shifting how they use AI inside real workflows, according to a new report from OpenAI, which frames the change as a move "from assistance to execution." Rather than using AI primarily to draft text, summarize documents, or answer questions — the pattern that dominated the first wave of enterprise adoption — companies are increasingly deploying AI agents that complete multi-step tasks with minimal human intervention: processing claims, reconciling records, routing and resolving support tickets, or managing parts of a sales pipeline autonomously.

The distinction matters because "assistance" and "execution" imply very different operational payoffs. An assistant that drafts a reply still requires a person to review it, copy it into the right system, and trigger whatever happens next. An execution-level agent closes that loop itself — it reads the incoming request, decides what to do, updates the relevant system of record, and moves the workflow forward, with a human only stepping in for exceptions or approvals. OpenAI's report describes enterprises restructuring processes around this capability rather than simply adding AI as a layer on top of existing manual steps.

For companies already running AI pilots, this is a useful checkpoint. Many organizations invested in copilot-style tools over the past two years — AI that helps an employee write faster or find information sooner — without ever removing the manual handoffs between systems. Those tools produced real but limited efficiency gains because the human was still the connective tissue between AI output and business action. The execution model described in the report replaces that connective tissue with orchestration: defined triggers, decision logic, and system integrations that let the agent act rather than merely advise.

This shift is unconfirmed as an industry-wide trend beyond OpenAI's own customer data and framing — the report is self-published and enterprise-focused, and independent verification of adoption rates outside OpenAI's ecosystem is not yet available. Readers should treat the specific figures and case examples in the report as OpenAI's account of its own customer base rather than a neutral market survey.

Still, the operational logic holds regardless of vendor. Smaller B2B companies don't need enterprise-scale infrastructure to apply the same principle. The gap between assistance and execution is usually not a model capability problem — most current AI models are already capable enough to make routing, drafting, and classification decisions reliably. The gap is integration: whether the AI's output actually writes back into the CRM, ticketing system, or ERP, and whether the next step in the process fires automatically. That is precisely the layer that determines whether an AI investment shows up as a line-item cost or as measurable time and headcount savings.

Companies evaluating their own AI stack should ask a narrow, concrete question: for each AI tool currently in use, does a human still have to act on its output before the workflow continues? If yes, that tool is still at the assistance stage, and there is likely a straightforward automation step that would move it to execution.

OpenAI publishes GPT-5.6 builder guide with new tool-calling and context specs

Mikhail Savchenko — Wed, 26 Aug 2026 05:57:56 +0000

OpenAI has published a builder's guide to GPT-5.6, aimed at developers building production applications on the model. The guide covers recommended patterns for tool calling, context management, and prompting, along with guidance on where GPT-5.6 diverges in behavior from earlier GPT-5 versions.

For consultancies and in-house teams that have deployed or are evaluating AI agents in sales, support, or operations workflows, the specifics in this kind of guide carry more weight than the headline model release itself. Model announcements tend to emphasize benchmark improvements; builder guides are where the practical constraints show up — how many tool calls a model will chain reliably in one turn, how it handles long conversation histories before losing earlier context, and what prompt structures reduce hallucinated function arguments.

For a 10-200 person B2B company, these details map directly onto real automation surfaces. A support agent that triages tickets and updates a helpdesk system depends on consistent tool-calling behavior — if the model's function-call reliability shifts between versions, an automation that worked last month can start silently misfiring: skipping a status update, mislabeling a ticket category, or truncating a customer's issue description because context handling changed. A sales-ops agent that pulls CRM records, drafts follow-ups, and logs activity depends on the same reliability. None of this shows up in a benchmark chart, but it shows up in a support queue or a CRM audit log within days.

The practical implication for operators is testing discipline, not blind upgrading. Any team running GPT-5.6 (or planning to move existing GPT-5-based automations onto it) should validate against their actual production tool schemas — the real CRM fields, the real ticketing categories, the real approval workflows — rather than relying on chat-only testing. Teams should also check whether the guide's recommended prompt patterns differ meaningfully from what existing automations use, since a prompt that was tuned for an earlier model version may need adjustment to avoid regressions in accuracy, latency, or cost per call.

There's a cost dimension too, though OpenAI's guide does not itself confirm new pricing — that detail remains unconfirmed pending separate pricing documentation. Teams budgeting for AI-driven support or sales automation should treat any assumed cost parity with prior GPT-5 versions as unverified until pricing pages are checked directly.

The overall takeaway for automation-reliant B2B operations is straightforward: a builder guide is a signal to re-test, not a signal to ignore. Companies with live GPT-5-family agents in sales, support, or ops should schedule a regression pass against the new guidance before assuming existing workflows carry over unchanged.

Cloudflare Adds One-Click Login Gate for Internally Built Apps

Mikhail Savchenko — Wed, 26 Aug 2026 05:32:35 +0000

Cloudflare has announced a one-click option to protect internal Workers applications with its Zero Trust Access product, addressing a security gap that has grown alongside AI-assisted app development.

The problem Cloudflare is targeting is specific: as AI coding assistants have made it fast and easy for non-specialist staff to build small internal applications — often called "vibe-coded" apps, built through conversational prompting rather than deliberate architecture — many of these tools have shipped without any authentication layer. A Worker deployed to handle an internal task, such as a lead-routing dashboard or a support-ticket lookup, is reachable by anyone who has or guesses the URL unless a developer explicitly adds a login step. For teams without a dedicated security function, that step is frequently skipped, not out of carelessness but because building the app itself already felt like the finish line.

Cloudflare's fix wraps deployed Workers with its existing Zero Trust Access layer in a single action, requiring users to authenticate through company identity providers (Google Workspace, Microsoft Entra, Okta, and similar) before reaching the application. No code changes, middleware, or separate security review are required from whoever built the original app. The feature is aimed squarely at the population of internal tools that previously existed in a gap: too small or informal to go through a full security review, but exposed on the public internet all the same.

For a B2B company in the 10-200 person range, this closes a class of risk that has become more common precisely because building software got easier. A sales operations lead who used an AI coding tool to build a quick CRM enrichment script, or a support manager who stood up a dashboard pulling from a helpdesk API, may not think to ask "does this need a login screen?" — and previously had no reason to, since standing up authentication used to require enough extra engineering work that it forced a conversation with someone senior. When the barrier to adding a login screen drops to one click, the excuse for skipping it disappears too.

The practical takeaway for operators is an audit, not a rebuild. Any internal Workers app built in the past year, particularly ones assembled quickly with AI coding assistance, should be checked for whether it sits behind Access or any other authentication. Where it doesn't, enabling the one-click protection is a low-cost fix. For teams evaluating which internal tools to build next, this also lowers the argument against building fast: if the security wrapper is now a checkbox rather than a project, the case for building internal AI-assisted tools without a security afterthought gets stronger, not weaker. The change does not fix authentication on other platforms — the risk described here is specific to Cloudflare Workers deployments and does not extend to internal tools hosted elsewhere, which still require whatever access controls that platform offers natively.