DEV Community: Tran Tien Van

Multimodal Content: Building an Access-First Review Workflow

Tran Tien Van — Thu, 13 Aug 2026 13:09:50 +0000

Meta plans to donate 15,000 Ray-Ban Meta AI glasses through Vision Ireland. For developers, the important signal is not the hardware; it is whether our content retains meaning outside a visual browser.

The interface is no longer just a screen

On August 13, 2025, Meta announced the Vision Ireland initiative to support greater independence for blind and low-vision adults in Ireland.

The initiative highlights a broader content problem. Written text may be heard. An image may be described. A page may be reduced to an answer. The source content still has to carry its essential meaning through each transformation.

Screen-only publishing fails that test when visual placement contains context that the spoken or extracted version does not retain. Multimodal content therefore needs a source that remains clear when people read, hear, describe, or question it through AI.

Treat accessibility elements as content interfaces

Alt text, captions, transcripts, clear headings, and plain language serve disabled people first. They also give ambient interfaces explicit content to read, describe, and summarize.

Use each element for a specific job. Alt text should preserve the relevant meaning of an image. Captions and transcripts should make audiovisual information available in another mode. Headings should state the structure clearly. Plain language should keep the explanation direct.

This is not a request to optimize accessibility fields for a crawler. Access is the purpose. Compatibility with AI interfaces is the secondary result.

Put four gates in the publishing path

A useful review does more than confirm that the page renders. Run the content through four transformations:

Listen to a read-aloud version and check whether the sequence and answer still make sense without the screen.
Compare an AI summary with the source and flag any loss or change of essential meaning.
Verify that important claims retain visible provenance when they are extracted.
Require human approval before publication rather than treating automated output as the final decision.

For developers, the practical move is to make each gate return evidence. Store the page or section reviewed, the transformed output, the provenance check, and the human decision. Define the escalation and rollback path before a failure occurs. That turns the checklist into a repeatable workflow rather than an informal reminder.

Make the source carry the context

Start with the content model. Give headings, summaries, captions, transcripts, and sources explicit places instead of expecting layout alone to communicate their roles. When an image carries essential information, pair it with text that preserves that information for someone who cannot see it.

A simple frontmatter model could look like this:

title: Multimodal Content Review
summary: How the content preserves meaning across interfaces
headings:
  - The interface is no longer just a screen
images:
  - alt: Relevant meaning conveyed by the image
    caption: Context available to every reader
transcript: Text alternative for audiovisual content
sources:
  - label: Meta Vision Ireland announcement
review:
  read_aloud_checked: true
  summary_fidelity_checked: true
  provenance_checked: true
  human_approved: true

Voice-first writing has three stated needs: direct answers, self-contained context, and visible sources. A development team can turn those needs into authoring prompts and review fields. Ask whether an answer names its subject, whether it makes sense outside the surrounding screen, and whether its source remains available beside the claim.

Then test the same content in more than one mode. Read it on screen, hear it in sequence, compare the generated summary, and inspect the extracted answer. The target is not identical wording. The target is consistent essential meaning.

Be explicit about the engineering costs

Validation notes, reviewer escalation, rollback rules, provenance checks, and human approval add work before publication. That is the cost of manual validation: the team spends more time checking content so plausible but unsupported advice does not pass review.

The other challenge is balancing search traffic against content accuracy. GEO or AEO gains should not justify publishing an extracted answer that changes the source meaning or loses its provenance.

Human approval is part of the workflow, not a decorative sign-off. The reviewer needs enough evidence to approve, escalate, or roll back the content.

Keep discovery in its proper place

GEO and AEO can benefit from direct answers, self-contained context, and visible sources. They remain benefits, not substitutes for access.

Vision Ireland places the priority in the right order: greater independence for blind and low-vision adults comes first. Durable performance across screen, voice, description, and AI answers follows from preserving meaning.

Which part of your current publishing stack is hardest to test reliably: read-aloud quality, summary fidelity, provenance, or human approval?

📖 Read the full guide → Multimodal Content: What Meta's AI Glasses Signal

Grok 4.6: A Practical Test Plan for Persistent VM Agents

Tran Tien Van — Thu, 13 Aug 2026 10:33:21 +0000

A 500,000-token context window is a capability, not a target. For Grok 4.6, the useful engineering question is whether the model and its separate persistent VM runtime survive your own production-shaped tests.

Start with two systems, not one

The August 12, 2026 launch documentation lists Grok 4.6 through the xAI API, Grok Build, Cursor, OpenRouter, Vercel, and Cloudflare. That distribution makes a trial accessible, but it does not establish that the stack is ready for your workload.

Grok 4.6 is the frontier-model candidate. Grok Bot is a separate persistent cloud-computer runtime for long-running agents. Keep that boundary visible in the test plan. If a combined agent fails, you need to know whether the model chose the wrong action, a tool call failed, or the runtime could not complete the work.

Treat context like a budget

The model supports a 500,000-token context window. The more important operational boundary arrives at 200,000 prompt tokens: reaching that point can move the whole request into a much higher pricing band, rather than charging a premium only for tokens above the line.

Set a warning before that boundary and require an explicit approval to cross it. Record prompt size for every evaluated job. Begin with the shortest context that can perform the task, then add material only when the accepted outcome improves enough to justify the extra token use and reviewer effort.

Long-running work adds pressure because stateful loops can carry growing context. A large window offers room for complex tasks, but it can also delay context discipline. That is an honest tradeoff: useful headroom can prevent truncation while making an expensive loop easier to miss.

Score production outcomes, not demo appeal

xAI's frontier-parity benchmark results are a reason to shortlist Grok 4.6, not proof of production fit. Use repeated, production-shaped tasks and retain the underlying measures:

Accepted outcomes: define completion criteria before the run and record whether the output passes them.
Tool reliability: capture attempted actions, successful actions, and failures by tool.
Latency: measure end-to-end completion time for each task class.
Token use: log prompt size and flag every crossing of the 200,000-token boundary.
Reviewer effort: track the human work required to verify, repair, or reject the result.

Do not compress these measures into one pass/fail number too early. A workflow can return an acceptable artifact while consuming too many tokens or too much review time. Another can look efficient while failing unpredictably when it reaches for a tool.

Put the persistent VM behind controls

Persistence is valuable when an agent needs to resume stateful work. The same Grok Bot runtime can expose browser, terminal, filesystem, and network access, which enlarges the security boundary beyond the model response.

Begin with reversible work whose outputs can be discarded. Isolate the VM, grant least privilege, place approvals before consequential actions, retain audit logs, enforce budgets, clean up state, and provide a kill control. Exercise those controls during the trial; a policy that has never stopped or cleaned up a run is not yet evidence of operational control.

Runtime evaluation should also verify tool reliability independently of model quality. A sound model decision does not rescue a failed terminal action, and a well-isolated VM does not make a weak answer correct.

Expand autonomy in stages

First, run Grok 4.6 against a fixed evaluation set with constrained or simulated tools. This establishes outcome quality, latency, token use, and reviewer effort without asking the persistent runtime to prove itself at the same time.

Next, test Grok Bot with tightly scoped, reversible jobs. Hold the task definition steady while you inspect resumability, access boundaries, auditability, cleanup, budgets, and the kill control.

Only then combine the chosen model workflow with the persistent VM. Increase permissions or duration after both cost gates and control gates pass. If the combined result regresses, the earlier baselines give you somewhere concrete to investigate.

The engineering case is a controlled enterprise trial, not an automatic migration. The August 12 release offers broad access and a large context window, but adoption should be earned by accepted outcomes and a runtime that stays governable.

Which production-shaped task would you choose for the first Grok 4.6 trial, and what exact cost or control result would stop the rollout?

📖 Read the full guide → Grok 4.6 and Persistent VM Agents

Beyond the Model: What WPP’s Data Blueprint Actually Teaches About Production AI

Tran Tien Van — Wed, 12 Aug 2026 10:04:16 +0000

WPP’s documented pattern combines shared data projects, separated processing compute, canonical audience definitions, and orchestrated pipelines.

The practical lesson for developers is simple: production AI starts below the model layer. Models need a shared, governed data backbone before they can support reliable marketing workloads.

Build a reusable boundary

Centralize identity, consent, lineage, and common cohort rules. Let domain teams own context-rich data products under shared standards.

This boundary gives enterprise marketing, martech, growth, RevOps, and data-platform teams a common foundation without stripping domain teams of ownership. Shared governance defines what must remain consistent; domain products preserve the context each workload needs.

Turn audience meaning into an interface

Canonical audience definitions should behave like a governed data contract, not logic copied into every pipeline.

Here is a vendor-neutral dbt pattern that makes that contract concrete. It illustrates the architecture rather than WPP’s exact schema:

-- models/interfaces/canonical_audience.sql
{{ config(materialized='view') }}

with identity as (
    select customer_id
    from {{ ref('shared_identity') }}
),

consented_customers as (
    select customer_id
    from {{ ref('shared_consent') }}
    where is_marketing_eligible = true
),

cohort_membership as (
    select
        customer_id,
        audience_key,
        audience_name
    from {{ ref('common_cohort_membership') }}
)

select
    identity.customer_id,
    cohort_membership.audience_key,
    cohort_membership.audience_name
from identity
inner join consented_customers
    on identity.customer_id = consented_customers.customer_id
inner join cohort_membership
    on identity.customer_id = cohort_membership.customer_id

The interface keeps identity, consent, and common cohort dependencies explicit. Domain teams can consume it and add context downstream without silently redefining the shared audience.

Review the pipeline before the prediction

Before celebrating model performance, review the operating system around it:

Freshness: Is the input current enough for the workload?
Pipeline reliability: Does orchestration behave consistently?
Retry safety: Can failed work be retried without unsafe side effects?
Lineage: Can the team trace an input through to its output?
Cost: Is the workload visible as an operating expense?
Service-level compliance: Does the system meet the commitment attached to the use case?

A model is only one component. The platform must also keep its data and operational promises.

Add capabilities in sequence

Start with governed analytics. Add predictive targeting once that foundation works. Introduce generative asset workflows only after review and safety controls can support them.

This sequence forces the platform to establish governance and operational discipline before adding more complex workflows.

Choose the architecture by workload

A customer data platform, warehouse-native design, and hybrid design are implementation shapes, not maturity rankings. Choose according to the workload rather than the category label.

The central tradeoff is shared control versus local context. Centralize reusable governance while leaving context-rich data products with the domain teams that understand them.

If you separate compute, you must explicitly unify your observability layer. Keep freshness, reliability, retry safety, lineage, cost, and service-level compliance visible across workload boundaries.

Look beyond the model

WPP’s blueprint points to a broader definition of production AI marketing: a reusable data system with enforceable controls, not a collection of model demonstrations.

Before adding another AI tool, inspect the foundation. Are identity and consent shared? Are audience definitions canonical? Can teams trace orchestrated work across separated compute? Can they review operational evidence before evaluating model output?

Where would you place a canonical audience interface in your stack, and what would you keep domain-owned?

📖 Read the full guide → AI Marketing Platform: WPP's Data-Engineering Blueprint

Muse Glimmer Production Readiness: A Practical Test Plan

Tran Tien Van — Wed, 12 Aug 2026 06:46:38 +0000

A reported 30-billion-parameter model that can fit in about 24 GB of VRAM in four-bit-class form sounds like a local-agent milestone. For practitioners, it is better treated as permission to test—not permission to deploy.

Start with the workflow, not the model card

Muse Glimmer reportedly combines vision, tool use, and consumer-GPU deployment. That is an interesting fit for private agent loops: sensitive inputs can remain in your environment, and steady workloads may avoid repeated cloud calls.

But “it loads” answers only a hardware question. A production agent also has to read your documents correctly, call the right tools, stay inside its permissions, expose useful traces, and recover when a step fails. Define that workflow before comparing benchmark numbers.

Write down the accepted inputs, expected outputs, tools the agent may touch, actions that need approval, and recovery behavior. A narrow task with an observable answer is a much better first candidate than a general autonomous assistant.

Separate memory fit from loop latency

Quantization tackles memory pressure. The reported four-bit-class variants use about 24 GB of VRAM, which could put evaluation within reach of a consumer-GPU machine. A fit result still does not answer whether the model clears workload quality and safety gates, so test the exact build you intend to serve.

DFlash targets a different constraint. It is a speculative-decoding approach intended to cut generation delay inside multi-step loops. The excerpt reports a 3.1x result on an NVIDIA RTX 5090, equivalent to roughly 210% above baseline.

That number is screening evidence. End-to-end latency also includes document retrieval, vision processing, tool execution, approvals, retries, and logging. Measure the complete task, not only token generation.

Run a workload-shaped gate

Build a fixed evaluation set from real inputs, difficult edge cases, and known failure paths. Then assess four gates:

Quality: Score task completion, grounded use of supplied documents, visual interpretation where required, and tool-argument accuracy. Include cases where the correct behavior is to stop or ask for review.
Latency and capacity: Record time to first useful output, full-loop completion time, GPU memory use, and behavior under the concurrency you actually expect. Compare quantized builds on the same machine.
Safety and control: Restrict tool access, require approval before consequential actions, and test malformed inputs, unavailable tools, and attempts to exceed permissions. Verify that every step leaves a usable trace.
Recovery and operations: Force timeouts and bad tool responses. Confirm fallbacks, rollback, alerting, and a safe way to disable the agent. Estimate the serving work your team will own.

Set thresholds before running the model. Otherwise, an impressive demo can quietly redefine “good enough” after the fact.

Treat compatibility as a starting point

VentureBeat reports that Meta released Muse Glimmer as a 30-billion-parameter model under Apache 2.0, distilled from Muse Spark. A Hugging Face post says the training data covers more than 100 languages and lists Transformers, llama.cpp, and vLLM support. VentureBeat also reports compatibility with OpenClaw and Hermes agent scaffolds.

Those names widen the plausible evaluation routes. They do not guarantee identical quality, latency, or operational behavior across runtimes and scaffolds. Pin the exact model build, quantization, runtime, prompt, tool schema, and hardware in every result you record.

Reported benchmarks should help you choose what to test first. Only your test suite can show whether the model handles your documents and failure modes.

Choose local or cloud by workload shape

Local inference is strongest when data sensitivity matters and demand is steady enough to justify owned serving. It can keep more data inside the environment and reduce dependence on a hosted vendor.

Cloud APIs remain attractive when frontier capability, elastic demand, or a low serving burden matters more. Their tradeoff is that data boundaries, call costs, and vendor dependence need explicit review.

The verdict is therefore “ready for workload-specific evaluation,” not “ready for production.” At Van Data Team, the decision begins with the workflow, data boundary, permissions, review gates, and recovery path. The model advances only when evidence clears each one.

Which failure path would you put in the first Muse Glimmer test suite: incorrect tool arguments, weak document grounding, or an unsafe recovery attempt?

📖 Read the full guide → Muse Glimmer: The Reported Local Agent Model, Reviewed

No-Code AI Agents: A Production Checklist for Marketers

Tran Tien Van — Tue, 11 Aug 2026 14:43:10 +0000

On August 10, 2026, Microsoft published a plain-language guide to building agents in Microsoft 365 Copilot. The practical shift is simple: Agent Builder gives non-developers a visual, natural-language route to a working agent.

No-code changes the interface, not the risk

For developers, that moves the difficult work toward the operating boundary, where access, approvals, recovery, and evaluation remain production concerns.

Agent Builder can ground an agent in approved knowledge, including SharePoint sites, uploaded documents, and Copilot connectors. The documented capability also extends to internal knowledge such as a shared inbox. A marketing or revenue operator can therefore assemble useful context without turning every change into an engineering request.

The critical boundary appears when the agent stops answering questions and starts taking proactive, independent actions. A chat waits for another prompt. A proactive action does not. That ability can create more value, but it also creates greater risk.

A developer reviewing this setup should ask more than whether the agent works. Which knowledge can it reach? Which actions can it take? What happens when an action fails? A visual builder does not settle any of those questions.

Start with the least dramatic workflow

The safest first workflow is bounded, repetitive, frequent, and easy to reverse. Bounded work has a clear edge. Repetition makes the task recognizable. Frequency gives the team regular opportunities to evaluate it. Reversibility limits the cost of a bad action.

Under that rubric, a broad workflow with unclear limits is a poor pilot. A narrower task is easier to observe, evaluate, and recover. The goal is not to showcase maximum autonomy on day one; it is to learn whether the agent behaves reliably inside a known operating envelope.

For marketing, growth, RevOps, and sales ops, the practical opportunity is to move manual, repetitive work into a governed workflow without waiting for engineers. Connecting approved campaign data or CRM assets could also reduce agency and engineering handoffs. The word “could” matters: this is an operating possibility, not a promised result.

Give every production agent five controls

Before treating an agent as production-ready, require:

Scoped access. Limit the knowledge and actions to what the workflow actually needs.
Approval gates. Put an explicit decision point before an action that should not run unchecked.
Logs. Preserve a trace of what the agent used and what it did.
Failure recovery. Define how the workflow stops or returns to a safe state.
Evaluation. Check the agent’s answers and actions against the intended task.

These controls are not decoration added after a successful demo. They are the working contract for a system assembled through a visual interface and natural-language instructions.

Keep documentation and recommendations separate

Microsoft documented the platform capability: professionals can ideate, build, and scale custom agents; those agents can use internal knowledge and take proactive action. Vanaxity’s contribution is the operating recommendation for applying that capability to marketing and revenue work, including autonomous SEO, GEO, and AEO content operations.

That distinction prevents overclaiming. Microsoft did not supply an ROI guarantee here, and these recommendations do not promise one. Even the possibility of reducing handoffs by connecting approved campaign or CRM assets remains conditional on how a team designs and governs the workflow.

Make the handoff concrete

The person closest to the process can specify which SharePoint site, uploaded document, Copilot connector, or shared inbox belongs in scope. A reviewer can then test the approval gate, inspect the logs, exercise the recovery path, and evaluate behavior before proactive actions are enabled.

Not every useful agent needs custom code. Every production agent still needs an explicit operating envelope, and developers are well placed to help make that boundary testable.

If your team adopted Agent Builder tomorrow, which bounded, reversible marketing workflow would you pilot first, and which of the five controls would be hardest to implement?

📖 Read the full guide → No-Code AI Agents: A Marketer's Playbook

Agentic Incident Response for GPU Clusters: A Safe Playbook

Tran Tien Van — Tue, 11 Aug 2026 07:30:56 +0000

HyperPod's Health Monitoring Agent (HMA) detects unhealthy nodes and performs supported mechanical recovery. AWS DevOps Agent is documented separately for incident triage and root-cause analysis (RCA).

That split is the practical starting point for agentic incident response—not an assumption that AWS ships a native bridge between the two.

Start with the documented boundary

Amazon SageMaker HyperPod documents a cluster health loop: health monitoring plus automatic node recovery. AWS DevOps Agent documents an investigation loop that works through supported inputs.

The cited material does not say that HyperPod events or HMA telemetry flow directly into DevOps Agent. It also does not establish a native HyperPod-to-DevOps Agent integration or a launch date for one.

That distinction changes the implementation plan. Treat any handoff between health detection and incident investigation as an interface you must verify. Document what starts an investigation, which evidence is available, what an agent may recommend, and what a person must approve.

Without that boundary, two individually useful capabilities can look like one end-to-end system when the sources only support two separate loops.

Optimize the whole MTTR path

Mean time to recovery covers six stages here: detection, triage, diagnosis, decision, remediation, and workload resume.

A faster health alert improves only part of that chain. HMA may identify an unhealthy node and carry out supported mechanical recovery, but the wider incident can still require diagnosis, a remediation decision, and confirmation that the workload has resumed safely.

Measure the complete path instead of stopping the clock at detection or node recovery. This makes bottlenecks visible. A team may discover that approval, evidence gathering, or workload resumption takes longer than finding the failed node.

The goal is not maximum agent activity. It is a shorter, explainable path to safe recovery.

Adopt autonomy in stages

A conservative rollout gives the team useful assistance without granting broad action rights on day one:

Keep the loops explicit. Use HMA for its documented node-health role, and use DevOps Agent for wider investigation through supported inputs. Do not represent a direct connection unless you can verify it.
Make the first RCA advisory. Let the agent propose a root cause and supporting evidence, then require a human to approve remediation.
Test the control surface. Check evidence quality, false positives, permissions, rollback, and auditability against thresholds your team defines.
Expand one permission at a time. Grant more autonomy only when the previous stage produces reliable evidence and a recoverable action path.

This sequence preserves a review point between diagnosis and action. It also creates a clear place to inspect whether the proposed remediation follows from the available evidence.

Make each gate observable

Evidence quality should answer a basic question: can an operator trace the RCA back to the incident inputs that support it? False-positive thresholds should reflect the failure cost your team is willing to accept.

Permissions need the same precision. An investigation capability does not automatically justify remediation authority. Keep the agent's allowed actions narrower than its ability to analyze until the team has validated the workflow.

Rollback must be more than a reassuring word. The team should know which automated actions are reversible and how recovery is initiated. Auditability should preserve who or what proposed, approved, and executed each action.

These are team-defined gates, not universal numbers. The right threshold depends on the operational risk and the reversibility of the action.

Accept the honest tradeoff

Human approval adds time between diagnosis and remediation. Early in adoption, that delay buys a deliberate checkpoint for weak evidence, false positives, and overly broad permissions.

Greater autonomy can remove some waiting, but it can also accelerate the wrong action if those controls are immature. Mechanical node recovery is narrower than resolving every operational incident, so success criteria should distinguish the two.

Agentic incident response works best as a governed operating model: supported automation where the mechanism is documented, explicit interfaces where it is not, and authority that grows only after the evidence earns it.

Where does your GPU incident process lose the most time today—triage, diagnosis, approval, remediation, or workload resume—and what proof would you require before an agent owned that step?

📖 Read the full guide → Agentic Incident Response for GPU Clusters

Realtime Voice Agents: A Design for Safe Native Tool Use

Tran Tien Van — Mon, 10 Aug 2026 12:52:25 +0000

OpenAI’s current Realtime documentation names three live-session tool paths: function tools, remote MCP servers, and connectors.

It does not verify hosted web search or sandboxed Python inside an active speech session.

Start with the documented boundary

Begin with evidence, not release language. Function tools, remote MCP servers, and connectors are supported during live conversations. The cited documentation does not support the more specific claim that a realtime voice agent can search the web or run sandboxed Python inside an active WebSocket speech session without custom proxy handling.

That is why this design should be treated as a proposal rather than a shipped capability. The distinction affects technical planning. If a team assumes hosted execution already exists, it may design around a runtime and permission boundary that the available source does not establish.

A useful architecture starts by labeling each component as documented, proposed, or application-owned. That keeps an implementation plan from quietly turning an aspiration into an API dependency.

Define what native execution would change

A voice workflow that needs current information or a calculated answer may route a tool request through custom proxy logic that pauses and resumes audio. That path adds latency and state handling.

A native hosted-tool design could remove that specific detour and shorten the route between a caller’s question and a spoken answer. It would not remove the need for an application backend. Teams would still be accountable for which tool runs, what it can access, what it costs, and how its behavior is reviewed.

The practical distinction is simple: native hosting could change where execution happens, but not who owns the decision.

Give search and code separate jobs

Web search fits questions that require current public information. Controlled code execution fits calculations and transformations. Treating them as interchangeable creates an unnecessarily broad permission surface.

For a proposed search tool, define when public information is actually needed and how tool accuracy will be evaluated. For a proposed code tool, constrain the operation to the calculation or transformation the conversation requires. Neither tool should become a route to unrestricted secrets, production credentials, or direct production-system access.

This separation also improves evaluation. A search case can test whether the right public information was retrieved. A calculation case can test whether the intended transformation was performed. Both can test whether the agent chose the right tool at all.

Use production gates that reflect live speech

A tool call that works in isolation is not enough. Production readiness depends on the behavior of the entire spoken interaction. Require evidence for these checks:

Latency: confirm the tool path keeps the conversation usable.
Barge-in recovery: verify the session recovers when the caller interrupts.
Tool accuracy: inspect both the selected tool and the returned result.
Cost: observe the operational effect of tool use.
Token budgets: enforce limits throughout the interaction.
Logs: preserve enough detail to review each tool decision.
Held-out evaluations: test behavior beyond the cases used during development.

These checks belong together. A correct calculation that arrives too late can still fail the conversation. Fast retrieval with poor tool selection can produce a confidently spoken error. Good average behavior can also conceal a weak failure path if evaluation covers only expected prompts.

Keep the security boundary explicit

A live voice agent must never receive unrestricted secrets, production credentials, or direct production-system access. A sandbox label, if such execution becomes available, would not answer the authorization question by itself.

Map permissions before connecting a tool. Record the tool decision in logs. Define review gates for changes to tool scope. Document what happens when access is denied, a tool fails, the token budget is reached, or the caller interrupts the response.

This is application governance, even when part of execution is hosted. Less proxy plumbing does not make the resulting system self-governing.

Apply an operator lens

At Van Data Team, we start by mapping evidence, permissions, review gates, and failure paths. Vanaxity applies that method across research, writing, illustration, publishing, and syndication. The same discipline is useful here because a voice answer can compress tool selection, execution, and presentation into a single conversational moment.

Native hosted tools, if verified, could make that moment faster and less fragile. They would also make weak controls less visible behind a smoother interaction. The bar for observability should therefore rise as orchestration becomes simpler.

If you were designing the first held-out evaluation for this proposed tool path, would you prioritize barge-in recovery, tool-selection accuracy, or permission denial—and why?

📖 Read the full guide → Realtime Voice Agents and Proposed Native Tools

Computer-Use Agents: A Production Engineering Checklist

Tran Tien Van — Mon, 10 Aug 2026 07:47:54 +0000

On March 23, 2026, computer use in Cowork and Claude Code was still a research preview.
That label is a useful engineering constraint: a capable screen-driving agent is not automatically a production-ready system.

Start with the integration boundary

The safest default is a structured integration. APIs usually give engineers better reliability, speed, testability, and cost control, so they should handle every step they can cover cleanly.

Visual control belongs in the remaining gap. It is useful when a workflow is GUI-only, trapped in legacy software, blocked by an incomplete API, or spread across applications. That boundary matters because screen control introduces a less structured execution surface.

Map the workflow before choosing the agent. Separate steps with stable API coverage from steps where the interface is the only practical path. A hybrid design can keep deterministic work structured while reserving visual action for the narrow part that needs it.

Put controls around the task

A prompt is not a production control. The operating environment needs to constrain what the agent can see, change, and continue doing.

Before rollout, require:

Isolation from unrelated applications, files, and credentials.
Least-privilege access limited to the task.
Approval gates before consequential actions.
Stop conditions for unexpected states or repeated failure.
Complete action records that show what the agent attempted.
A defined recovery path when the run does not finish safely.

These controls have an honest cost. Approval gates reduce uninterrupted autonomy, while tight permissions can block an unforeseen but legitimate step. The alternative is an agent with a wider blast radius and less oversight. Production design is the act of choosing that boundary deliberately.

Evaluate the run, not the demo

A polished screen recording answers only whether one path worked once. Task-level evaluation has to judge the final state and the behavior that produced it.

Final-state correctness should be explicit: which file, field, or application state must exist when the task ends? Then measure retries, latency, token budget, unsafe attempts, and recovery. A run that eventually reaches the right result after unsafe actions should not pass merely because the last screen looks correct.

Retries expose brittle navigation. Latency shows whether the visual path is operationally acceptable. Token budget keeps the evaluation connected to cost control. Unsafe-attempt tracking tests whether the controls actually intervene. Recovery checks whether the workflow can return to a known state instead of leaving partial changes behind.

The test set should include the states that trigger an approval, a stop, and a recovery. That makes the safety model observable rather than aspirational.

Read product status precisely

The timeline shows why capability and readiness should be evaluated separately. Anthropic introduced computer use with Claude 3.5 Sonnet in October 2024 and opened it through the Anthropic API. On March 23, 2026, release notes described direct computer use in Cowork and Claude Code as a research preview. Cowork itself reached general availability on April 9, 2026.

Those labels can coexist because a generally available product may contain a capability with a different maturity designation. Engineers still need to validate the exact workflow, controls, and failure behavior they plan to operate.

CNBC's March 24, 2026 coverage described Claude navigating applications, working with spreadsheets, and completing multi-step desktop tasks. That demonstrates a broader task surface; it does not remove the need for application-level boundaries.

Make the rollout decision

Prefer an API when it can complete the step. Add visual control only when the interface is the practical route. Isolate that route, grant the minimum access, place approvals before consequential actions, define stop conditions, and preserve the full action record.

Then evaluate correctness, retries, latency, token use, unsafe attempts, and recovery as first-class outcomes. If the team cannot state what stops the agent or how a partial run is recovered, the workflow is not ready for production.

Which step in your current workflow truly requires visual control, and what approval would you place immediately before it?

📖 Read the full guide → Computer-Use Agents: An Engineer's Production Guide

Agentic AI in Marketing: A Workflow-First Operating Model

Tran Tien Van — Sun, 09 Aug 2026 08:54:38 +0000

Reporting, qualification recommendations, and outbound drafts are the safest first scopes for a marketing agent: each leaves room for review before an irreversible action.

OpenAI’s August 7, 2026 HSP GRUPPE case points to the engineering reason—capacity comes from redesigning daily work, not merely rolling out software.

Translate the case carefully

HSP GRUPPE is a professional-services network of legally independent tax-advisory, auditing, and law firms. The source case concerns those professional services, not marketing agents. Its value for marketing teams is as an operating-model pattern: place AI inside a named workflow, give the workflow an owner, train users, appoint champions, record a baseline, and install review gates.

That distinction matters. A team can buy ChatGPT and count prompts while still lacking an answer about whether agent-led qualification, campaign reporting, or personalized outbound saves time, improves quality, or introduces unacceptable risk.

Build permissions around reversibility

A developer implementing agentic AI in marketing should separate generating information from taking action. One implementation of the article’s rule is:

Begin with reporting, where the agent prepares information for review.
Add qualification recommendations, while a person retains the decision.
Produce outbound drafts, with approval before anything is sent.
Expand operating scope only when held-out evaluations, production traces, and incident handling satisfy standards approved in advance.

The sequence is deliberately conservative. The agent earns scope through adoption, measured outcomes, and working controls; autonomy is an output of evidence, not the starting configuration.

Measure behavior and outcomes together

Active use belongs on the scorecard, but not by itself. Track it alongside time saved, quality, customer outcomes, cost, latency, and control. Those seven dimensions keep activity separate from effectiveness in the scorecard.

Start with the baseline tied to the named workflow. For campaign reporting, compare the same work before and after agent assistance across the listed measures. For qualification, keep the recommendation under review until the agreed evidence clears the gate. Each team still has to pre-approve its own standards for those dimensions.

For an implementation, make ownership and review state visible in the workflow. A useful record can identify the workflow, owner, baseline, current approval gate, and evidence from evaluation or production traces. Incident handling also needs to exist before additional autonomy is granted. That makes the control model inspectable rather than implicit. Keeping those fields together lets a reviewer compare the approved boundary with behavior recorded in production traces.

Treat content agents as pipelines, not text boxes

Vanaxity, Van Data Team’s content agent, is the article’s concrete marketing example. It applies research, data pipelines, review gates, publishing, and syndication to content intended for keyword rankings, AI Overviews, LLM citations, answer-engine extraction, and structured data across SEO, GEO, and AEO.

For developers, the important mechanism is the gated pipeline. Each stage can have a clear input, output, owner, and approval condition. The content target may span several discovery systems, but the operating discipline remains tied to the workflow and its evidence.

Keep the tradeoffs visible

This approach asks for owners, training, champions, baselines, and reviews before broader autonomy. That is more operating work than buying access and watching prompt counts. It also refuses to treat held-out evaluations as the whole answer: production traces and incident handling must meet the pre-approved standard too.

There is another limit to make explicit. HSP GRUPPE offers evidence from tax advisory and related professional services; the marketing framework is a translation of that case, not a reported marketing experiment. Teams still need their own baselines and outcome measures for the workflows they choose.

Where would you draw the first permission boundary in a real marketing-agent build, and what evidence would let you move it?

📖 Read the full guide → Agentic AI in Marketing: Lessons From HSP GRUPPE

WeatherNext: A Practical Checklist for Trusting Cyclone AI

Tran Tien Van — Sun, 09 Aug 2026 06:27:24 +0000

A three-day WeatherNext cyclone forecast is about as accurate as leading systems' two-day forecast—roughly a full day of useful lead time.

That is a meaningful result. It is not, by itself, a deployment decision.

Split the headline into three tasks

DeepMind's Nature paper, published August 6, 2026, reports state-of-the-art results for cyclone track, intensity, and wind structure. Those are separate prediction jobs with different failure consequences. A composite score can rise while one job remains unacceptable.

Before testing the model, write acceptance criteria for each task and forecast horizon. Decide what evidence would justify a trial, what would trigger human review, and what would stop use. This prevents a strong aggregate result from silently becoming approval for every use case.

Evaluate the distribution, not just the winner

WeatherNext's generative architecture creates about 1,000 plausible forecasts. That changes the evaluation target. You are not judging one deterministic answer; you are judging a distribution whose spread should communicate uncertainty.

Average error still matters, but it cannot show whether probabilities are trustworthy. Compare predicted probability ranges with observed outcomes, inspect whether uncertainty expands in difficult cases, and check whether rare but consequential paths receive plausible weight. A narrow ensemble can look precise while being poorly calibrated. A broad one can be honest yet less actionable.

Use one review sheet across experiments:

Record track, intensity, and wind-structure results separately; compare equivalent lead times and note that WeatherNext's three-day result is roughly comparable to leading two-day forecasts.
Test calibration across the roughly 1,000 generated scenarios, not only the best member or ensemble mean.
Run generalization checks outside the easiest slices and document where confidence degrades.
Measure inference cost for the full ensemble at the cadence your workflow requires.
Validate the output in a shadow workflow with explicit escalation and human fallback.

Treat openness as the start of verification

This release is more than a closed demo. Google DeepMind published a model family, research evidence, and reproducible software artifacts. The repository makes code and weights available under Apache 2.0 and CC BY 4.0 licensing terms, which gives independent teams a real path to test the claims.

Reproducibility still requires discipline. Pin the artifact you evaluate, preserve configuration and data assumptions, and make each result traceable to the exact run. An open repository lowers the access barrier; it does not choose your thresholds or prove fitness for your environment.

The cyclone model operates at roughly 28 x 28 km resolution. That number belongs in the acceptance review because spatial resolution and downstream decisions must be considered together. Do not let a global performance summary answer a local suitability question it was not designed to answer.

Separate research evidence from operational readiness

The work was backed by operational validation during the 2025 Atlantic hurricane season. That is stronger evidence than a paper metric alone, but production adoption still needs a controlled path.

Start with replay tests that your team can audit. Then run the model in shadow mode beside the current system. Log inputs, ensemble outputs, reviewer decisions, latency, and exceptions. Set explicit gates for promotion, rollback, and human intervention. At Van Data Team, this is the pattern we apply to production AI workflows: observable pipelines, named review points, and a fallback when model confidence or system health is not good enough.

Keep the tradeoffs visible

The extra lead time is valuable only if the forecast arrives within the operational window. Generating about 1,000 candidates gives a richer uncertainty picture, but it also makes inference, storage, review, and monitoring more demanding. Open weights make inspection possible, while leaving validation ownership with the adopter.

The practical lesson is simple: do not ask whether WeatherNext “wins.” Ask which task wins, at what horizon, with what calibration, at what runtime cost, and under which operating conditions. Scientific ML becomes trustworthy through a chain of evidence, not a single score.

Which gate would your team require before moving a WeatherNext evaluation from shadow mode into an operational decision workflow?

📖 Read the full guide → WeatherNext: Evaluating AI Cyclone Forecasting

Claude Opus 5 on Google Cloud: A Production Adoption Guide

Tran Tien Van — Sat, 08 Aug 2026 13:48:43 +0000

Claude Opus 5 is now available on Google Cloud’s Agent Platform—but a capable model is not a production system.
For hours-long workflows, the hard part starts where the model call ends: permissions, state, evaluation, supervision, and recovery.

Start with the boundary, not the benchmark

Google Cloud now offers Anthropic’s most advanced Opus model for long-running agents, coding, and professional work. That is a useful capability upgrade for engineering, platform, AI-builder, and growth teams.

It is not an operational guarantee.

A production agent can call tools, change data, accumulate state, consume budget, and continue after the original prompt is no longer a useful control surface. The adoption question is therefore not merely, “Can Claude Opus 5 complete the task?” It is, “Under what authority can it act, how do we observe the run, and how does it stop safely?”

That shift matters most in multi-agent systems. An orchestrator may delegate work for hours, but every delegated step still needs an explicit boundary.

Separate retention from access

Zero Data Retention and Identity and Access Management solve different problems.

ZDR limits retention at the covered model-serving layer. It should not be treated as a blanket answer for every place data might exist in an application architecture. Teams still need to define what their own state stores, traces, and recovery records contain.

IAM controls who and what can access the model. Apply least privilege to the humans, services, and agent identities involved in a run. Model access alone should not imply permission to use every downstream tool.

This separation is easy to miss: retention is about what remains at a covered layer, while authorization is about who or what may act.

Build the control plane around the model

Before granting meaningful autonomy, make these six controls concrete:

Bounded tools: expose only the operations and parameters required for the job.
Durable state: preserve enough run state to inspect, resume, or recover work.
Approval gates: require review before consequential actions cross a defined boundary.
Stop conditions: specify when time, cost, policy, or task state must halt the run.
Tracing: record the decisions and tool activity needed to reconstruct execution.
Recovery logic: define what happens when a step fails or leaves partial work.

These controls are connected. A stop condition without durable state may halt a run that cannot be recovered. A trace without bounded tools can explain an overly broad action after the damage is done. An approval gate without a clear decision record gives the reviewer little basis for approval.

Google Cloud’s reported security fallback belongs in this control plane, but its role is narrow: it is a defensive routing control. It is not authorization for an agent to automate consequential security actions. Those actions still need deliberately scoped tools and an approval policy.

Expand autonomy with evidence

Adopt Claude Opus 5 in stages. Begin with a narrow workflow, restricted tools, and explicit review points. Then use held-out evaluations that were not part of prompt or workflow tuning.

The release criteria should cover four dimensions: quality, cost, latency, and policy performance. A run that produces strong output but violates a policy is not ready. Neither is a compliant workflow whose cost or latency makes the operating model unsustainable.

Expand permissions only when the evidence clears the next stage. If a new tool, task class, or agent role changes the risk surface, evaluate that change before treating prior results as transferable.

Accept the real tradeoffs

Governance adds friction. Approval gates can slow a workflow. Tracing and durable state require infrastructure. Narrow tool permissions can limit what an agent completes without help.

That friction is visible and measurable; unbounded failure is usually neither. The practical goal is not maximum autonomy. It is the highest level of autonomy that continues to meet the team’s quality, cost, latency, and policy thresholds.

Claude Opus 5 provides the model foundation. A production-ready system still comes from the boundaries, evidence, and recovery paths built around it.

If you were piloting Claude Opus 5 next week, which gate would you require before its first write action—and what evidence would let you relax it?

📖 Read the full guide → Claude Opus 5 on Google Cloud: Adoption Guide

BigQuery Data Transfer Service: A Practical Decision Guide

Tran Tien Van — Sat, 08 Aug 2026 11:16:48 +0000

A remote MCP Server can make BigQuery Data Transfer Service agent-callable. That does not make create, change, backfill, or delete safe defaults.

The useful engineering question is where managed ingestion fits, how to compare it fairly with custom ETL, and which decisions still need a person.

Start with the connector boundary

Prefer managed DTS when a supported connector can load the source into BigQuery with limited transformation. That boundary is more useful than a blanket “managed is better” rule.

A supported path can remove the need to keep brittle, hand-built ETL glue around. But if the workload needs transformation beyond that limited case, the connector alone does not settle the architecture. The team still has to compare the managed route and the custom route against the same requirements.

This is the first honest tradeoff: DTS can reduce what you operate, while custom ETL can remain relevant when the workload falls outside the supported, limited-transformation path. The framework should expose that boundary instead of hiding it behind a product label.

Run one comparison, not two narratives

A DTS evaluation and a custom ETL evaluation are only comparable when the inputs and success conditions match. Use one workload and one definition of acceptable behavior.

Hold these four elements constant:

The workload being moved into BigQuery.
The acceptance rules used to decide whether the result is usable.
The latency measurements used to compare delivery.
The total-cost model used to judge the operating choice.

This prevents a common reasoning error: giving one option a friendly test and the other a hostile one. The outcome can favor managed DTS or custom ETL; what matters is that the evidence was produced under the same rules.

Treat the remote MCP Server as a control surface

Agent-callable ingestion changes the interface, not the ownership of the outcome. A remote MCP Server should be governed as a control surface. It is not blanket authority for an agent to create, change, backfill, or delete transfers.

Translate that principle into an explicit decision boundary. The agent can help assemble or trigger work within the allowed scope, while a human remains responsible for consequential claims, recommendations, and publishing decisions. The article’s broader discipline is useful here: automation should make review easier to perform, not easier to skip.

This approach also makes failures easier to reason about. Instead of asking whether “the agent” is trusted, ask which transfer action is allowed, what evidence supports it, and where approval belongs.

Connect research to delivery

The guide’s content workflow has five connected stages: research, validation, review, improvement, and reporting. Treating them as separate checkboxes weakens the final result.

Start with search intent before drafting or optimizing. Before delivery, validate metadata, headings, depth, links, and keyword usage. Then use review findings to revise the draft. Review is valuable only when it changes the artifact that readers and stakeholders receive.

This process matters to developers because the deliverable is more than prose. SEO, content, and operations stakeholders need to see how the recommendation was reached and what remains unresolved.

Make the report operational

The final report should name the artifacts, findings, and next actions. That creates a handoff someone else can inspect without reconstructing the entire evaluation.

For the DTS decision, the artifacts may be the comparison inputs and reviewed draft. The findings should capture whether the supported-connector and limited-transformation conditions hold. The next actions should identify what needs validation, improvement, approval, or follow-up. Those categories come directly from the framework; avoid padding them with invented certainty.

Human approval remains important at the points the guide names: claims, recommendations, and publishing decisions. That is a deliberate constraint, not a failure of automation.

The practical default

Choose managed DTS when the connector is supported, the load targets BigQuery, and transformation is limited. Escalate to a fair custom ETL comparison when those conditions do not cleanly hold. In either case, preserve the same acceptance rules, latency measures, and total-cost model.

For agent-driven transfers, govern the remote MCP Server action by action. For the content that explains the decision, connect intent, validation, review, improvement, and reporting. The shared principle is simple: convenience can start the workflow, but evidence and approval finish it.

Which boundary would be hardest to define on your team: connector fit, fair cost comparison, or approval for create, change, backfill, and delete actions?

📖 Read the full guide → BigQuery Data Transfer Service: Zero-Code, Agent-Callable Ingestion