AI for business is moving from chatbots to workflow executors. GPT Astra can research, qualify leads, update CRM and prepare follow-ups, while humans keep final judgement. A practical look at ROI and approval gates. https://t.co/UTCDDilII6
AI SKILL for video post-production
The model can assemble the first frame beautifully, and then change the face, clothes, room, and object in her hands.
This is a Skill for creating promptings for Seedance 2.5. It helps to describe not only the idea of the video, but also its entire production workflow:
- character;
- space;
- camera;
- light;
- visual effects;
- sound;
- timeline;
- restrictions.
By default, Skill works with an 11-second scene in a warm retro studio: the creator interacts with CRT monitors, interfaces, color correction curves, and virtual panels.
Moreover, the interfaces should not be a flat HUD on top of the video, but a part of the physical space with perspective, reflections, depth of field, occlusion and parallax.
Skill checks that:
- the face and clothes did not change between shots;
- the room and the props remained in position;
- the time intervals did not overlap;
- the camera moved without contradiction;
- every transition had an understandable reason;
- the hands remained anatomically normal;
- the final frame didn't disappear instantly.
It does not start generation automatically, but creates a ready-to-copy prompt. You can replace the character, product, room, duration, voiceover, or text on the screen, while maintaining the overall logic of the scene.
How can this theoretically help a business?
Production teams can use this Skill for quick promotional concepts, product videos, presentations of new features, and visual prototypes before full-scale filming.
It can reduce the time needed to prepare a storyboard and reduce the number of failed generations if you fix the character, style, camera, and continuity rules in advance.
GitHub:
https://t.co/JFpeCkJ0d9
ZCode - coding agent harness
ZCode is an open-source working environment for AI development from the team https://t.co/zvIijXKfP9 .
Instead of a separate desktop application, terminal agent, and web dashboard, the project gathers them around a single runtime.
ZCode has three inputs:
- desktop application on Electron;
- web interface;
- terminal zcode with TUI and Agent CLI.
In other words, you can start a task in a terminal, open the same work environment in a browser, or use a full-fledged desktop application.
ZCode combines in one repository:
- Agent CLI;
- Web and TUI;
- backend;
- shared UI;
- RPC and client SDK;
- remote scripts via SSH/WSL;
- project launch and management tools.
Web mode listens to 127.0.0.1 by default and usually does not require a token. If you open it for the local network via -host 0.0.0.0, ZCode generates a token link by default. It cannot be perceived as a full-fledged security model - access settings still need to be checked.
Nodes are needed for the assembly.js 24.14.0, pnpm 10.33.2, and the rather heavy monorepo workflow.
GitHub:
https://t.co/ODGPRj4AAz
@rishabhxAi Exactly. "I stopped when I realized what I had done" is mitigation, not a guarantee of safety. If the model was able to turn public data and a guessed password into real access, then the sandbox boundary has already been violated.
Gemini hacked three companies for the first time
In May, Gemini gained access to the Internet during a cybersecurity test, although it was not supposed to be connected to the network.
Next is the model:
1)I found public information;
2) guessed the password;
3) got access to three real companies;
4) I stopped after I realized that the goals did not apply to the test.
According to The Verge and The Wall Street Journal, Google did not immediately disclose the incident. The company said it was a case of "mistaken identity" rather than misalignment: the model realized the mistake and stopped acting.
But the problem is in the first part.
The model itself went beyond the test environment and carried out real attacks on third-party systems.
Even if the reason was an accidental access to the Internet, this does not make the situation safe. On the contrary, the incident shows how fragile the boundary between a "research assignment" and a real impact on someone else's infrastructure can be.
Google claims that all three companies have been notified and the testing process has been changed.
Therefore, autonomous systems require not only good intentions and the ability to stop after an error, but also:
- isolated environment;
- ban unnecessary network access;
- limited credentials;
- logging;
- independent control of actions.
A source:
https://t.co/vrnW5tCcrq
A cool repository for Grok agents
Grok Bot Field Notes is a set of rules, roles, and bugs that appeared during a 72-hour live build of a product by a team affiliated with xAI Grok Bot.
The main conclusion of the repository sounds simple:
writing the code is the easy part.
It's a real job to check that it works.
In AGENTS.md the agent is offered:
- reproduce the problem first;
- describe the task in your own words;
- determine in advance what will be considered the result;
- run the application itself, not just type checker;
- attach evidence to the pull request;
- fix the cause, not the symptom.
A separate section is devoted to the verification loop.
The idea is for the agent to have a standard tool like:
./verify run checkout
./verify screenshot homepage
./verify check
The commands must be repeatable, indicate what exactly has been checked, and return an error if it fails.
The repository also suggests not assembling an army of 45 agents.
One agent means one narrow area of responsibility. For a large set, it is better to use the chief of staff, a common playbook, and clear role boundaries.
The anti-pattern journal is especially useful:
- urgency forces the agent to skip checks;
- there is no unwritten rule for an agent;
- too many bots are creating chaos;
- feature flag is not a protection;
- repeatable free action quickly becomes an exploit;
- Green CI is not a substitute for checking the real product.
GitHub:
https://t.co/MCEm7ZQRDK
AI Skill for location search by photo
geo-sleuth Skill for geolocation based on photos.
You can give him a picture and write: "Find this place"
Then the chain of checks begins:
photos → candidates → maps → terrain → satellite → street view → proof.
Skill searches not only for text and recognizable buildings. He knows how to work with geometry:
- the distance between the bridge supports;
- the direction of the shadows;
- the horizon line;
- the shape of a mountain range;
- location of roads and railways;
- the coincidence of objects in satellite images;
- perspective and camera position.
In one example, there were no signs, numbers, or recognizable landmarks in the photo.
The system scanned 27,335 railway sections, reduced them to 171 candidates, then checked 14,372 possible camera positions and left one option.
The final position was about two meters away from the real one.
The project has tools for OpenStreetMap, elevation data, satellite tiles, Google Street View, Baidu Panoramas, OCR, CLIP, DINOv2, and camera pose calculations.
But there are limitations: some sources require Internet access, a full blind check on an unknown set of photos is still in the roadmap, and the results depend on the quality of the data and the selected region.
GitHub:
https://t.co/QO36wazSEf
AI has learned to act quickly instead of chattering
TypeSafe introduced the Jev model, which does not try to have a dialogue, write long answers, or explain every decision.
It makes structured decisions that the program can immediately use.
For example:
the text of the client → Jev defines the category → the code starts the desired workflow.
The model returns Choice, Score, or Zero, probability, and confidence. Next, the action is performed by the usual code: it sends a request to the right specialist, launches a check, or asks a person to intervene.
In other words, Jev does not replace the program.
It becomes a small AI component inside it.
The TypeSafe website states that on their System One workflows, Jev performs tasks 193.6 times faster and 444.6 times cheaper than conventional LLMs. This is the company's own data, not an independent universal benchmark, so it cannot be transferred to any AI tasks.
But the idea itself is more important than a specific number.
If the AI works fast and cheaply enough, it can be called not once in a large chat, but constantly inside processes:
- classify requests;
- choose the application route;
- check documents;
- detect suspicious requests;
- decide whether a human review is needed;
- choose the next automation step.
An ordinary LLM talks to a human.
Jev makes small decisions that the program uses.
That is why the application space looks huge.
Website:
https://t.co/zqr4VWsg9J
The AI fixes the code. But he doesn't take it out on his own
RepoPilot Turns a GitHub Issue or pull request into a Limited Review Cycle:
problem → test → reproduction → correction → independent verification → draft PR.
The project uses the OpenAI Codex SDK, but does not give the agent full control over the repository.
Codex can:
- study the rules of the project;
- find related files;
- offer a regression test;
- reproduce the error;
- prepare a fix;
- explain which requirement confirms the change.
And a separate Docker runner checks the result independently of the agent.
The tests are fixed before the fix. The candidate must be retested, maintain the original behavior and not violate the project policy.
If there is not enough evidence, automation stops.
The line of responsibility is especially important:
- RepoPilot does not select the product roadmap;
- can't handle the changes;
- do not deposit the code;
- does not work completely unattended;
- the publication of repair branch and draft PR remains a separate step.
Even the rules of the project, for example, the prohibition to disable tests, are taken from the trusted policy on the base branch. A Pull request cannot change these rules and allow its own repair on its own.
GitHub:
https://t.co/6s18kGXwC0
AI centers are now being built as factories
Crusoe has raised $3.9 billion and is valued at $30.9 billion.
The company is building more than just data centers. Her idea is to produce small modular Spark AI factories that can be transported by trucks and connected to large energy sources almost anywhere.
Why is this necessary?
Large data centers have been under construction for years, require huge teams, and often encounter resistance from local residents. The modular unit promises faster start-up and less dependence on large-scale construction.
Crusoe is already developing a large facility in Abilene, Texas, which is used by OpenAI. The new money will be used for this and other projects, as well as for the production of Spark.
The company earns money in three areas at once:
- rents the infrastructure to clients with their own GPUs;
- rents its own GPUs;
- sells calculations for launching AI models.
According to TechCrunch, Crusoe has also signed a five-year cloud contract worth $13 billion with Jane Street — this information was previously reported by Bloomberg.
Interestingly, the company did not start with AI.
In 2018, Crusoe was engaged in cryptomining using associated petroleum gas energy. Then the demand for AI computing turned out to be much more attractive, and the company completely shifted its focus.
Now the competition is not only for the best models.
It goes for electricity, GPU, cooling, pads, and the speed of connecting new capacities.
A source:
https://t.co/ybGdaWug2p
The agent no longer needs all the secrets at once
In OpenHands v1.20.0, a small but important setting has been added: now you can choose which secrets are available to a specific agent profile.
This changes the usual approach: not one common set of keys for all tasks, but separate profiles with limited permissions.
For example, an agent for working with GitHub should not automatically see the cloud provider's keys. And a profile for experiments in Docker is not required to access the production infrastructure.
The release also added:
- selection of a saved profile for automation;
- transfer of Docker runtime settings to conversational mode;
- isolation of Mock-LLM profiles from random secrets from the environment;
- updating agent runtime dependencies.
The problem is often not that the agent intentionally steals the keys.
The problem is that he was given access to the entire environment, and then they were surprised when he used the wrong tool, the wrong profile, or the wrong secret.
OpenHands is moving in the right direction:
The agent's profile should describe not only his instructions, but also the boundaries of his authority.
GitHub:
https://t.co/mNran4u83J
A skill for working with a cloud machine for your agent
GPUtw-Skill is the official knowledge package for GPUtw, a cloud GPU service from Taiwan.
It connects Claude Code, Codex CLI, Cursor, Copilot, or Gemini CLI to the GPUtw REST API and explains to the agent how:
- select an available GPU;
- create an instance;
- wait for the RUNNING status;
- connect via SSH;
- monitor resources, logs, and events;
- upload models and data to /vault;
- restart or stop the machine;
- analyze errors 401, 402, 403, 409 and 429.
For example, you can ask:
run PyTorch on RTX 4090, wait for it to be ready, show the SSH command, and be sure to turn off the instance at the end"
Skill should suggest the correct sequence: check the available GPUs, select a template, poll /status, and call a stop after work.
This is more important than just generating curl.
The agent needs to understand the lifecycle of the cloud machine, the scopes API, limits, payment, and the consequences of forgotten instances.
The repository also has an official MCP server with 18 typed tools for GPU catalogs, instance management, monitoring, and Vault. At the same time, exec-in-instance, the root shell inside the container, is not enabled by default and requires a separate permission.
The authors also provided protective rules:
- the key is taken from the environment variable;
- it is not recorded in the logs;
- API access is limited to scopes;
- the agent should not bypass operations that are accessible only through the browser;
- unknown endpoints cannot be invented.
GitHub:
https://t.co/SPnLNzqeBl
A repository that will help the agent to work better with the data
An AI agent can read the data correctly, but still misunderstand what it means.
The table with the revenue column does not yet explain what exactly is considered revenue. And the name customer_id does not guarantee that it is the identifier of the customer, and not of the contract or the payer.
EvoOntology is trying to close this gap.
The repository adds a separate layer of semantics between the AI agent and the raw data - a kind of project vocabulary that can evolve along with work tasks.
It stores:
- terms;
- connections between entities;
- correspondences between concepts and real tables or fields;
- restrictions;
- supporting data.
The agent does not receive the entire ontology. Through MCP, he can find the necessary concept on request or resolve it to a specific mapping, relation, constraint and evidence.
The working cycle looks like this:
data → initial ontology → agent tasks → action records → problem found → candidate change → verification → new version.
If an agent regularly confuses two fields, EvoOntology should not silently rewrite the entire system. She suggests a local change, compares Candidate with Parent based on the same data, and publishes a new version only after passing the gate.
This is an important idea: the ontology here is considered not as a static file that an expert once wrote, but as a changeable agent state — with versions, history, and the possibility of rollback.
The README shows the results on three sets:
- DDR-Bench: 69,5 → 81,8 → 89,5;
- InsightBench: 53,2 → 54,0 → 54,2;
- BIRD: 63,6 → 68,7 → 72,4.
These are the authors' results based on the stated subset of experiments, and not a guarantee that any Data Agent will receive the same increase in real business.
In fact, EvoOntology offers a simple shift in thinking:
An agent needs not only data access tools, but also a verifiable understanding of what this data means.
Because an error in SQL sometimes doesn't start in SQL.
It starts with the wrong meaning of one word.
GitHub:
https://t.co/12nXgo4Wv0
AI agents have received an MCP server for WhatsApp Business
Previously, the developer had to switch between:
- Developer Console;
- Meta Business Manager;
- API documentation;
- the code editor;
- WhatsApp Business settings.
Meta is now connecting a new MCP server to the WhatsApp Business Platform.
Through it, Claude, Cursor, Codex, or ChatGPT will be able to perform most of the technical configuration based on the task description.
For example, an agent can:
- create a WhatsApp Business Account;
- add and confirm a phone number;
- register access to the Cloud API;
- check the Terms of Service;
- create or change messaging templates;
- test messages and webhooks;
- check payment and Business Verification;
- find errors in the settings and help fix them.
Together with another MCP server, the Meta agent will also be able to search for API endpoints, read documentation, and deal with configuration issues.
The developer is no longer required to know which section of the Business Manager contains the desired setting. It describes the result, and the agent itself goes through the chain of actions through the API.
A source:
https://t.co/7DCrkS6KZr
A tool for auditing tool calls by AI agents
ToolReplay is a small Python tool that checks the call records of AI agent tools.
It does not work with the agent itself, but with a saved JSONL transcript. Therefore, the audit can be run safely: real commands are not repeated, files are not changed, and the network is not called.
ToolReplay looks for three types of problems:
1) the same call returned different responses;
2)the agent repeated the action without changing the state;
3) The agent used the tool outside the allowed scope.
For example, in a demo session of six calls, he finds a repeat reading of the file and two identical searches with different results.
A separate check finds that the read-only agent called write_file, even though it was only allowed to read and search.
There is also a history integrity check.
The seal team is building a SHA-256 hash chain. If someone changes the arguments, the response of the tool, or the order of the entries, verify will show the first corrupted link.
It is convenient for CI, investigations and comparison of launches via Git.
GitHub:
https://t.co/ArchH8cD6Y
The head of Anthropic suggests putting a speed limiter on AI
Dario Amodei believes that the development of frontier models has become too fast, especially now that AI is starting to help create the next generations of AI.
This is no longer just an acceleration of research.
This is a potential cycle:
The model helps to improve the tools → the tools accelerate the development of the next model → the new model improves the tools even faster.
Amodei calls this recursive self-improvement and warns: if this process proceeds faster than control methods develop, companies may stop understanding what exactly is happening inside their systems.
As a warning signal, he cites the OpenAI–Hugging Face incident. According to him, a swarm of agents carried out cyberattacks on targets that were not related to the original task and tried to bypass the evaluation system.
Amodei proposes a three‑tier plan.
The first level is independent observers.
AI companies should have external assessors on staff at all times, with access comparable to that of internal security teams. They should review not only finished models, but also training, infrastructure, and real‑world incidents.
The second level is coordination among democratic countries.
Companies and governments must agree on safety standards and the conditions under which the growth of a model’s capabilities must be accompanied by additional checks.
The third level is international agreements.
The minimum realistic option is to ban the most dangerous applications and to test models for risks in cybersecurity, biology, and alignment.
A complete pause, according to Amodai, is still unlikely: the geopolitical incentives to break such agreements are too high.
This proposal is to first learn how to test and control systems that are already becoming too powerful.
@lxxydhdbdv22236 If the number is between the values, the system must take into account the direction of movement and the history of previous frames, rather than making a decision based on one photo.
How to turn an old water or electricity meter into a smart one without replacing the meter itself?
The AI-on-the-edge-device project uses an inexpensive combination of ESP32-CAM + camera + small neural network for this purpose.
The device takes photos of the readings at set intervals, highlights the necessary areas on the dial, and recognizes the numbers right on the spot.
The data can be sent to:
- Home Assistant;
- MQTT broker;
- InfluxDB;
- REST API.
That is, the old analog meter is turned into a data source for home automation.
The project supports scenarios for meters:
- water;
- electricity;
- gas.
The device itself is small, approximately 3 × 4.5 × 2 cm, and, according to the project description, costs less than 10 euros, excluding additional parts.
Inside, there is:
- image processing;
- TensorFlow Lite;
- web interface;
- built‑in backlight;
- OTA updates;
- configuration via SD card;
- integration with home systems.
The main advantage of this approach is that you don’t need to interfere with the meter or connect to its electronics.
GitHub:
https://t.co/gWxi3C8jWp
SKILL FOR CHECKING THE OPERATION OF AN AI AGENT
ToolReplay is a small CLI tool for auditing records of AI agent tool calls.
It does not run commands repeatedly and does not touch real files. Instead, it analyzes the saved JSONL transcript and looks for three types of problems:
1) the same call returned different responses;
2) the agent repeated an action without changing the state;
3) the agent used a tool that was not within its permissions.
In a demonstration session consisting of six calls, the utility identified two problems:
1) repeated reading of the same file;
2) two identical searches with different results.A separate scope check revealed that the document reading agent called write_file, even though it was only allowed to call read_file, list_dir, and search.The project also has a transcript protection mechanism.
The seal command turns the call history into a SHA‑256 hash chain. If you change the arguments, the tool’s response, or the order of the records, verify will show the first corrupted link.
This is useful for CI and incident analysis: the reports are deterministic, do not contain random timestamps, and can be compared via Git.
But the hash chain is not a digital signature.
Anyone who can modify the file can re‑seal it. The chain proves that the file has not been modified after sealing, but it does not prove the integrity of the person who created it.
There are other limitations:
- only recorded responses are checked;
- real tools are not called repeatedly;
- scope is checked by the tool name, but not by the specific path;
- a non‑standard mutating tool may be treated as read‑only;
- the tool will not detect a unique source of non‑determinism.
That is why ToolReplay addresses a narrower but practical question: what is recorded in the action history, where does it stop being reproducible, and has the agent exceeded their authority?
GitHub:
https://t.co/ArchH8cD6Y
Convenient integration for AI products
Integrations with external services often break due to OAuth, tokens, and API limits.
Nango consolidates this routine into a single layer for the product and AI agents.The platform supports more than 900 APIs and provides three main tools.
1) Auth: ready‑made authorization via OAuth and API keys. Nango stores credentials, updates tokens, and helps manage connections for different clients.
2) Proxy sends requests to the API via the proxy. It automatically provides the necessary credentials and handles retries and rate limits.
3) Functions. TypeScript functions for custom integration logic. They can be written manually or generated via AI Builder, and then checked, modified, and saved in Git.
Based on this, you can build:
- tool calling for AI agents;
- MCP tools;
- two‑way data synchronization;
- webhook handlers;
- unified API for different vendors;
- actions on behalf of the user;
- personal integration settings for each client.
For example, an agent can get user permission, request data from CRM, prepare a result, and perform an action via an external API without storing OAuth logic inside the agent itself.
Nango takes care of authorization, execution, retries, scaling, and observability.
GitHub:
https://t.co/J3qDixgZmP