Workflow Automation

TL;DR for operators An agent’s ability to complete a desktop task depends on more than the model operating it. The commands exposed by the application, the effort required to discover them, and the ability to inspect saved results can materially change performance. ANIS, an Agent-Native Interface Synthesizer, generates agent-oriented commands from existing software capabilities and validates their effects on persistent artifacts.1 On 368 desktop tasks, DeepSeek V4 Flash improves from 68.5% success with native SDK access to 74.5% with ANIS, while average online token consumption falls from 84.4K to 21.2K per task. ...

TL;DR for operators An AI system can save a successful workflow and still spend substantial effort reconstructing how that workflow was originally assembled. Efficient reuse depends on whether the completed procedure is directly available to subsequent planning as a callable operation. FormCraft proposes a capability architecture in which primitive and composed operations share typed interfaces, retain their formation provenance, and can participate in further compatible composition. Verification determines which operations enter a persistent library. ...

TL;DR for operators An automation agent may retrieve the right information, update one application, and complete several intermediate operations before failing its final task. A binary success test assigns that entire attempt zero reward, even when parts of the workflow were executed correctly. Explorer-Zero1 demonstrates a training alternative: let one agent generate achievable tasks through actual environment interaction, record verifiable intermediate states, and let another agent learn from those checkpoints. ...

TL;DR for operators A DNA sequencing pipeline can finish every computational stage successfully and still produce results that warrant investigation. BaseCamp1 illustrates this problem with a scenario in which individual processing metrics appear acceptable, yet their combined results show an unusually high rate of reported genetic differences. Completing the workflow does not establish that its scientific conclusions are credible. ...

TL;DR for operators When an LLM produces a bad executable workflow, the failure may not mean that it misunderstood the business rule. It may have selected the right actions and still lost parameters, Boolean relationships, or graph ordering while writing the full structure. That distinction changes the engineering response. In Generating Workflow DAGs from Natural Language with Non-Reasoning LLMs, Anand Iyer, Bhanu Khetharpal, Srinivas Upadhya, and Ramkumar Rajagopal test an architecture that keeps language interpretation in the LLM but moves deterministic graph expansion into conventional code.1 On their 635-rule benchmark, GPT-5.3-chat improves from 56.4% to 80.6% LLM-judge validity when paired with registry selection, a compact intermediate representation, and deterministic compilation. Exact-condition accuracy rises from 56.5% to 82.2%. ...

TL;DR for operators A system can discover agent “skills” that look coherent to humans and still fail to make an agent more capable. That is the useful result of Automating SKILL.md Generation for Computer-Using Agents via Interaction Trajectory Mining.1 The authors build a pipeline that cuts GUI interaction histories into segments, clusters those segments into candidate routines, generates explicit skill specifications, and trains a Qwen3-8B policy with Group Relative Policy Optimization, or GRPO, to compose the resulting skills. ...

TL;DR for operators Most agent guardrails behave like stop signs. They inspect a proposed action, decide whether it looks safe, and then allow or block execution. This is neat, legible, and often operationally clumsy. Real agent failures are not always cleanly harmful from the first word. A useful business request can be contaminated by a prompt injection, a malicious tool response, or an unsafe intermediate plan. Blocking the whole task may reduce risk, but it also throws away the legitimate work. Excellent safety theatre, less excellent operations. ...

Video is where AI demos go to become expensive. A model can describe a short clip. It can answer a question about a few sampled frames. It can even sound confident while doing so, which is apparently a product feature now. But business video work is rarely “what is happening in this five-second clip?” It is usually messier: find the exact moment in a two-hour training recording, count repeated actions without double-counting adjacent clips, verify whether an event appears in audio, subtitles, and frames, or decide whether a safety incident is real rather than just visually similar to one. ...

Multi-agent AI has entered its “surely more agents will fix it” phase. This is an understandable phase. Also a dangerous one. When a single model struggles with a hard reasoning task, the obvious enterprise instinct is to add another model: one to plan, one to solve, one to check, one to summarize, one to look professional in the architecture diagram. The diagram improves immediately. The system may not. ...

Demo day is not discovery day Demo day has a familiar rhythm. An AI system reads papers, proposes an idea, edits code, runs an experiment, drafts a manuscript, and perhaps even produces something that looks suspiciously like a conference submission. The slide title then arrives with great ceremony: autonomous scientist. The paper AutoResearch AI: Towards AI-Powered Research Automation for Scientific Discovery is useful because it interrupts that ceremony before everyone starts clapping at the PDF generator.1 Its central move is not to deny progress. Current systems really can automate meaningful pieces of research work. They can search, summarize, plan, code, run tools, assemble figures, and draft reports. That is already operationally important. ...