Andrew James (from left), Neil Morrison, Natalia Kurz and Michael Neiss work on a prototype of their weed-killing robot ahead of The Farm Robotics Challenge, which they won on May 21.
By Holly Hartigan
A team of Cornell undergraduates beat 95 other teams to take the grand prize at The Farm Robotics Challenge with their invention: an autonomous robot that kills weeds with electricity.
Their robot can travel through a vineyard or orchard without a human operator, zapping weeds with a small amount of electricity, saving labor and energy and preventing crop loss, without the use of herbicides.
Led by Andrew James, an agricultural sciences major in the College of Agriculture and Life Sciences (CALS), the team of agricultural specialists and engineers studied the existing electrical weeding technology, developed their own low-energy system and built a working prototype over the course of four intense months.
Natalia Kurz, a biological engineering major in CALS, said the project required a lot of late nights. “There were fears for us, like, was it just going to be for nothing?”
Now, James and his co-founders are using the $50,000 grand prize to form a company – Rootline Robotics – to continue working on the robot. Agricultural technology firm Reservoir sponsored the award and will host the startup at its incubator in Sonoma, California.
“I’ve always been interested in building a startup within the ag-robotics space,” James said. “So after winning this competition and seeing all the amazing support from so many different industry stakeholders in this really exciting collaboration, it makes a lot of sense to keep going.”
Weeds are a huge challenge in orchards and vineyards because they steal water and nutrients, especially in the spring, according to Steve Selin, owner of South Hill Cider in Ithaca.
“The weed pressure is very strong, and the grasses grow right up to the trees because we can’t afford to weed whack or mulch them as much as we would like to in order to control them,” he said. “If the trees get really stressed out, they’ll just drop the fruit.”
To control weeds, organic growers typically employ string trimming, mowing and mulching, which are all very labor intensive. Existing electric weeders require an operator, consume a lot of energy and cost $150,000, on average, which is out of reach for most growers, James said.
Selin provided feedback to the students as they developed their robot and said he is excited to try out Rootline’s new technology.
“In May and June, if you could do something to knock the weeds back enough that they’re not going to compete with the trees, then the rest of the year you wouldn’t have to worry about it,” he said. “You can let them come back and have positive impacts, like shading the soil, which would help the soil microbes to have a healthier ecosystem.”
“Robotics is many different systems in one,” Kurz said. “It is interdisciplinary by definition.”
Next, the Rootline team will work on improving its technology and validating it with growers before bringing it to market, all while Kurz and Neiss finish their degrees.
Neiss said the way the team came together felt a bit like destiny.
“If you have many different minds in one room that gives you the ability to reach solutions that are going to be the most feasible and effective,” he said.
There are over 70 coding agents on the market: Claude Code, Codex, Cursor, Copilot, Devin, and a long tail of smaller entrants showing up in engineers’ newsfeeds every week. Someone runs a benchmark, posts the leaderboard, and by the end of the week, half the org wants to try whatever is in first place. The pace behind that impulse is real: these tools are improving every few weeks.
The problem is what “trying a new model” actually costs. Claude Code only runs Anthropic’s models. Codex only runs OpenAI’s. Pick one and you’re locked into the model provider that comes with it.
If you want to try a different model, such as something open-weight and less expensive for a given task, you’re not just changing a setting. You’re switching the whole tool. Chasing a model, price point, or benchmark means adopting a new coding agent, and a new vendor.
In organizations, that’s where the review shows up. Every new coding agent presents the same three questions:
The answers change tool to tool, but the review itself is nearly identical every time, and legal, security, and finance end up doing it from scratch each time.
To bridge this gap, DataRobot OpenCode delivers a state-of-the-art coding agent that supports model choice across closed, open, and bring-your-own options, all while maintaining rigorous governance.
Getting started only takes a few minutes.
DataRobot OpenCode runs on the DataRobot LLM Gateway, the same governed entry point already used for every model on the platform, so the agent inherits that governance instead of routing around it.
All of it sits behind one already-approved key. Switching from a closed frontier model to an open-weight one for a cost-sensitive task is a config change, not a new vendor relationship.
DataRobot agent skills, including Agent Assist, come preinstalled, so OpenCode is enterprise-ready on day one, not just model-flexible. That’s the same skills layer DataRobot ships for Cursor, Claude Code, and Gemini, applied here to an agent that isn’t tied to any single vendor’s models.
Installation is three commands from the DataRobot CLI. No separate API key to request, no model configuration to write by hand.
You can install and launch OpenCode in your terminal or run it from the DataRobot UI:
brew install datarobot-oss/taps/dr-cli
# installs the DataRobot CLI in your terminal; not needed inside the DataRobot UI
dr plugin install opencode
# installs the OpenCode plugin
dr opencode
# launches OpenCode, already wired to the Gateway with DataRobot skillsPick a model from the LLM Gateway via:
/modelsThen, launch Agent Assist to use natural language to design, test, build, and deploy production-grade agents:
dr assistGet started today. Run the following commands in your terminal:
brew install datarobot-oss/taps/dr-cli
dr plugin install opencode
dr opencodeThe post DataRobot OpenCode: your coding agent, your model choice appeared first on DataRobot.
Agents rarely act alone. A user asks an agent to do something. The agent calls a tool. The tool calls another agent. By the time work gets done, three or four actors have touched the request, each acting on behalf of the one before it.
Identity has to survive that chain. At every hop, you need to answer two questions, not one. Who originally requested this? And which actor is making this specific call? Lose either answer and you lose the ability to authorize the call correctly or explain it afterward.
The standards already model this. RFC 8693 defines token exchange: an actor trades the token it received for a new one to make the next call, without discarding who came before. The token carries two claims that matter here.
The sub claim is the subject, the original principal. It is the user who started the whole thing, and it does not change as the request moves down the chain.
The act claim is the actor, the party making the current call. It does change. And when one agent calls another, act nests: Agent B acting on behalf of Agent A acting on behalf of the user. Nested act is the only honest way to represent a multi-hop chain, because it keeps every link instead of collapsing them.
The shortcut is to flatten the chain. Instead of exchanging tokens and nesting act, an agent re-mints a fresh token that says, in effect, “this is me, calling on my own behalf.” It is simpler. It also destroys the chain.
Now sub points at the agent, not the user. The original principal is gone. Attribution is gone with it: the downstream tool sees the agent and has no idea whose request set this in motion. And because the tool only sees the agent’s identity, it authorizes against the agent’s permissions, which are broader than what this specific task should allow. You over-grant on every downstream call.
This is the confused deputy: a process acting with authority that was granted to someone else, used for a purpose the grantor never intended. The flattened token is how the confused deputy gets created in an agent system. The preserved chain is how you avoid it. The difference is whether you can still inspect, at the tool, who asked and who is acting.
This is not only a standards story. The chain is preserved or destroyed at two protocol surfaces the primary audience is deploying right now.
Agent to tool runs over the Model Context Protocol (MCP). The mid-2025 MCP spec adopted OAuth 2.1 and RFC 9728 protected-resource metadata. That matters because it lets an agent discover what authorization a tool requires instead of hardcoding it. The agent reads the resource’s metadata, learns where to get a token and what scope it needs, and asks for exactly that. Discovery is what makes scoped, per-tool authorization practical at runtime.
Now the deployed reality, because the spec is not the same as what is running. A large share of MCP servers in the wild ship with weak or absent authorization. The protocol supports doing this correctly. Many deployments do not. That gap is the entire subject of this series: the standards exist, and the systems built on top of them skip the parts that protect the chain.
Agent to agent runs over A2A and its Agent Cards. An Agent Card is a discoverable declaration of what an agent is, what it can do, and which authentication schemes it accepts. It is how one agent learns how to call another without a human wiring the two together in advance. The card is also where an agent advertises whether it expects a delegated token or will happily take anything. Read the cards in your ecosystem. They tell you where the chain is respected and where it is about to be flattened.
These two surfaces, MCP and A2A, are the concrete places the delegation chain is either inspectable end to end or quietly collapsed into a token that lies about who is acting.
Delegation is not a token handed down the line. It is a chain, and a healthy chain is one you can inspect at every hop: sub fixed on the original principal, act nested through every actor that touched the request. Flatten it and you have built a confused deputy that over-grants and cannot be audited.
In your own systems, the chain is preserved or lost at MCP and A2A. Check two things. Do your agents exchange and nest tokens, or re-mint flat ones? And do the MCP servers and Agent Cards in your ecosystem actually require delegated authorization, or do they accept whatever shows up?
You can now describe an agent, give it an identity, and carry that identity through a chain of calls. The next question is where the rules for all of this live. Who decides what an agent is allowed to do, and what happens the moment an agent has to act somewhere its own platform does not reach? That is the next post.
The post Delegation chains, the confused deputy, and the protocols you actually deploy appeared first on DataRobot.
We are currently witnessing a profound architectural inversion in the world of enterprise computing that will define the next decade of corporate IT strategy. For the better part of a decade, conventional IT wisdom dictated that all significant computing workloads […]
The post Navigating How the Rapid Enterprise Push Toward Localized AI Mandates a Radical Shift in Cloud Strategy appeared first on TechSpective.
Implementation of conversational AI in Medicine and Healthcare has been a trend in the healthcare industry to deliver outstanding care services ever like before. Yes, Artificial Intelligence (AI) has become a promising technology to transform the Patient Care Industry.
The healthcare and medical sector is accelerating digital services and optimizing patient care, especially in emergency conditions, healthcare companies are adopting conversational AI applications like chatbots to monitor and provide 24/7 care services to their patients.
Be it for in-patients or out-patients, AI-powered Healthcare Chatbots are increasingly using across healthcare companies for ensuring better experiences for patients. Today, herein, we have compiled a list of the top benefits of investing in AI chatbots for healthcare and medical services.
For delivering convenient and instant care and support services to patients, healthcare service providers are widely using AI-powered medical chatbots. Yes, a medical chatbot is an intelligent and collaborative AI solution developed for better managing routine healthcare functions and delivering virtual care services to patients.
Let’s see a few top applications of medical chatbots:
The role of AI-based chatbot solutions for healthcare is prominent for automating various regular tasks like recording logs, reminding medications, generating invoices, and monitoring patients’ health, etc. Offering their patients 24/7 non-stop care services and responding to them instantly on their issues about care services.
It is one of the key roles of AI-based medical and healthcare chatbots. 85% of healthcare service providers are investing in AI chatbots for keeping care services available for patients all the time.
Using Natural Language Processing (NLP) or text-to-speech techniques, interactive and conversational AI chatbots deliver outstanding digital services. Appointment scheduling apps are the best examples that we must discuss here.
Based on the user’s preferred time and specialty, AI chatbots will automatically recommend an available list of doctors and makes booking faster. Hence, such intelligent processes through AI chatbots will make the process virtual and improve the patient experience.
Likewise, top AI chatbot apps in healthcare will also help service providers virtually respond to patient’s issues if any.
It is one of the significant healthcare chatbots use cases that we must discuss. By deploying an AI-enabled chatbot in place, healthcare service providers can virtually monitor a few cases anywhere at any time. It will save the physicians valuable time and improves their productivity in handling other emergency cases.
Reminders on medicine intakes and refills are the best Chatbot use cases in the healthcare industry. A conversation AI chatbot plays significant in monitoring and tracking the patient’s medication schedules. Hence, AI medical bots play a key role in sending notifications on medicines intake, dosage, and refills.
Further, a few chatbots are also designed for sending auto reminders on the time to get their kid’s vaccinations and stay on top of the health risks.
Here are other advanced healthcare chatbots that are making disease detection functions seamlessly. The conversational bots are designed and developed to analyze the symptoms and recommend a proper diagnosis for patients on booking time slots for the required specialists.
These type of chatbots have shown their potential during the COVID season. AI apps with real-time tracking of self-reported symptoms features have assisted many people in predicting the probable infection and saved their lives from hazardous viral diseases.
On the other hand, chatbot applications in healthcare are used for automating front-desk and back-office support functions. OP data management, payments management, and invoice management functions are automated by deploying AI-powered medical & healthcare chatbot applications. It will lower operational cost and improves business efficiency.
AI and machine learning-based healthcare apps with in-built chatbots play a major role in online insurance claiming and processing functions. Supportive document scanning, verifications, credit edibility checking, processing coverage for a medical procedure, and insurance disbursement & record maintenance, everything can be handled robustly using AI insurance chatbots. Hence, insurance claiming bots will save the time of insurers and healthcare service services and make the process faster.
NLP plays a key role here to better analyze the user’s voice or text-based questions. Conversational question-answer type chatbots are the next biggest assets for healthcare service providers.
These types of AI healthcare or medical bots are well-trained with a set of pre-defined questions and answers. So, when a user asks a question from the list, the chatbot gives an automated response in minutes.
Here is one of the best applications for using AI chatbots in the healthcare and medical industry. Patient experience and satisfaction is the growth indicator of a healthcare service company. It can be achieved by using AI-powered intelligent feedback analysis chatbots.
Leveraging emotional tracking tools, AI healthcare chatbots can easily detect the experiences of in-patients and out-patients and derive valuable insights. These insights would help service providers for improving service quality and enrich patients’ experiences.
AI virtual assistants in healthcare will deliver post-operative care services. Integrating conversational AI chatbots into the intelligent telemedicine system will help to assess patient conditions and enhance the efficiency of outpatient care services. Such virtual nursing assistants will optimize the postoperative experiences and increase business scalability.
Finally, AI healthcare bots or medical chatbots are also best for better data management. AI-powered data management chatbots will automatically log the entire patient’s data like name, age, and details of physicians, treatment, payment, insurance, etc. Hence, the scope for errors in data is zero.
These are the top 10 applications of AI chatbots in the healthcare and medical industry. The AI-based chatbot applications will deliver incredible benefits to both healthcare service providers and patients.
Your.MD, Sensely, and Ada are a few most popular AI-based medical chatbots used to transform healthcare operational ways and improve the quality of personal healthcare services.
Looking to harness the power of conversational AI in your healthcare business?
Let’s Discuss Your AI Chatbot Development Requirements!
[contact-form-7]Here are a few advantages of AI healthcare chatbots:
The cost of AI Chatbots development will depend on its type and functionalities. On average, an AI chatbot application development with basic features will range from $15,000 to $100,000+.
However, the cost of conversational AI solutions is high when you use machine learning, predictive analytics, and NLP-like other revolutionary technologies to ensure robust performance. Using AI-like technologies, our expert mobile app developers build interactive mobility solutions for businesses across various industries.
Let’s hire the best AI Chatbot development company- USM Business Systems.
[contact-form-7]
Governing 5 agents is a review process. Governing 500 agents is an infrastructure problem.
Manual reviews and team-level approvals work when a handful of agents are visible and closely watched. Once agents spread across business units, tools, and environments, that oversight breaks down.
Enterprises need an AI agent governance model that includes centralized identity, reusable policies, and enforcement that holds across the whole agent workforce.
A small number of AI agents can be governed through direct review. Teams can document purpose, inspect prompts, approve tool access, monitor usage, and revisit an agent when something changes.
The challenge escalates as the AI agent workforce expands across business units and systems. Consider a healthcare scheduling agent connected to an electronic health record, appointment platform, and patient communications system. One version may be approved to read scheduling data and send reminders. Another may inherit broader access, use an unapproved model, or route protected health information into the wrong workflow.
Across dozens of agents, a single permission change, tool update, or policy gap can spread before anyone sees it.
The consequences extend far beyond governance operations. A small configuration error can expose sensitive data, disrupt services, trigger an audit, and force expensive remediation across multiple systems. As the agent workforce grows, teams must manage thousands of relationships among agents, tools, data, identities, policies, and environments while keeping controls consistent as the system changes.
Governing an agent workforce should begin during design and prototyping, before agents spread across teams and production environments. Retrofitting identity, inventory, policy enforcement, and monitoring after deployment adds cost, disruption, and control gaps.
| Where governance breaks | What happens at enterprise scale | What enterprises need |
| Inventory | Agents appear across teams, tools, and environments without a complete record. For example, a governance team may set out to catalog 30 agents and uncover 120 prototypes running in approved platforms, notebooks, internal apps, automation tools, and third-party services. | A living registry of every agent, owner, business purpose, deployment environment, and connected component. |
| Identity | Shared credentials, broad service accounts, inherited human access, and agent-to-agent handoffs make it difficult to determine who acted and under what authority. | A unique identity for every agent, tied to scoped permissions, approved tools, data access, and business purpose. |
| Policy consistency | Teams interpret the same rule differently, and controls may apply in one workflow or environment but not another. | Central policies that propagate across the agent workforce based on risk, data sensitivity, business purpose, and environment. |
| Environment drift | Controls can weaken or disappear as agents move through development, staging, production, cloud, on-premises, or third-party platforms. | Cross-environment enforcement that keeps identity, permissions, monitoring, and review requirements intact throughout the lifecycle. |
Governance at the scale of an agent workforce requires infrastructure that manages individual agents and coordinates the system around them. An agent is like a machine on a factory floor: teams still need to inspect it, tune it, replace faulty parts, and verify that it operates safely.
At enterprise scale, maintenance is only part of the job. Teams also need to know how each machine connects to the production line, which inputs it can use, which actions it can take, and how the system responds when conditions change.
For agent systems, that means governing prompts, tools, MCP servers, vector databases, data sets, guardrails, APIs, downstream workflows, and predictive and generative models — including the LLMs that power agent reasoning — through a shared control layer.
| Governance area | What teams need to control |
| Agent registry | Which agents exist, who owns them, and where they run |
| Agent identity | How each agent is authenticated, authorized, and tracked |
| Policy propagation | Which rules apply across agents, tools, data, and environments |
| Permission scope | What each agent can read, write, update, delete, or trigger |
| Tool access | Which tools, APIs, MCP servers, and workflows each agent can invoke |
| Component lineage | Which prompts, models, data sources, and versions each agent uses |
| Runtime enforcement | Which actions are blocked, escalated, logged, or allowed |
| Monitoring | Which behaviors indicate drift, misuse, cost spikes, or policy violations |
| Audit trails | What the agent saw, selected, called, returned, decided, and did |
| Review triggers | Which changes require reapproval before continued use |
This infrastructure gives enterprises a practical way to scale agents without relying on scattered spreadsheets, one-off approvals, or disconnected logs.
Three of these areas are worth unpacking. Agent identity, policy propagation, and cross-environment enforcement are what separate governance that works for one agent from governance that holds up across hundreds of them.
You can’t scope permissions, propagate policy, or attribute actions without first assigning every agent a durable, unique identity. Agent identity gives every agent a durable record and a controlled way to act. That record should connect the agent to its owner, business purpose, risk tier, approved tools, data access, deployment environment, and review history.
For example, a procurement agent may compare vendor quotes and draft a recommendation while remaining blocked from approving purchases or changing supplier records.
Identity also separates user authority from agent authority. A human user may have access to a system, but an agent acting on that user’s behalf should still operate within its own approved scope.
Centralized identity also needs to persist across agent-to-agent workflows. When one agent delegates a task to another, governance teams need to know which agent initiated the handoff, what data and instructions moved with it, and what authority the receiving agent was allowed to exercise. Each agent should enforce its own permissions while the system preserves a trace of the full delegation chain. Otherwise, a routine handoff can unexpectedly expand access, drop an important constraint, or make responsibility difficult to reconstruct.
This distinction becomes critical at enterprise scale. When hundreds of agents act across systems and delegate work to one another, security and governance teams need to attribute behavior to specific agents, detect anomalous access patterns, trace handoffs, and revoke permissions without disrupting unrelated workflows.
Policy propagation turns governance rules into reusable controls across the agent workforce. A policy might define which data classes an agent can access, which tools require human approval, which actions are prohibited, which logs must be captured, or which environments can run high-risk workflows.
At the scale of an agent workforce, these rules should be applied centrally and inherited by the right agents based on risk tier, business purpose, environment, and data sensitivity. A high-risk HR agent, for example, should inherit stricter review, logging, and bias monitoring requirements than a low-risk internal documentation agent.
Policy propagation also helps teams manage change. If a new regulatory requirement affects agents that process personal data, governance teams should be able to identify impacted agents, update the relevant policy, apply it across environments, and verify enforcement.
Without reusable policy controls, each agent becomes its own governance project. That’s not only exhausting for AI, security, and governance teams; it also creates inconsistent enforcement, missed controls, and real operational risk as the agent workforce grows.
Cross-environment enforcement ensures that governance controls — identity, approved scope, policy requirements, monitoring rules, and audit expectations — move with an agent across development, staging, and production, as well as across cloud, on-premises, and third-party platforms.
Agents don’t stay still: they connect to new tools, switch models, receive prompt updates, and expand into new workflows.
This is especially important for enterprises that run agents across multiple clouds, on-premises systems, and third-party platforms. A governance program tied to only one deployment environment leaves gaps wherever agents are built or deployed elsewhere.
Cross-environment enforcement should cover access, tool invocation, parameter constraints, guardrails, logging, escalation, and review triggers. It should also prevent unapproved changes from silently expanding what an agent can do.
Informal governance starts to strain as agents spread across teams, environments, and business processes. Before growth outruns the governance model, leaders should confirm that the organization can answer these questions:
Weak answers signal that agent growth is outpacing the governance model. Strong answers give AI, security, governance, and business teams the control infrastructure required for production scale.
Agentic AI can create real business value, but production scale requires more than architecture and deployment. Enterprises need governance mechanics that hold up when agents spread across teams, systems, and environments.
The shift from 5 agents to 500 agents changes the job. Centralized identity, policy propagation, cross-environment enforcement, monitoring, auditability, and lifecycle review become the operating foundation.
These workforce-level controls are one part of the broader agentic AI lifecycle. For a deeper look at governing agents, tools, permissions, monitoring, auditability, and production risk, download The Enterprise Guide to Agentic AI Governance.
Agent workforce governance, sometimes called AI agent governance, is the practice of managing many AI agents through centralized controls for identity, ownership, permissions, policy enforcement, monitoring, auditability, and lifecycle review.
A small number of agents can often be reviewed manually. Hundreds of agents require infrastructure for centralized identity, reusable policies, cross-environment enforcement, runtime monitoring, and audit trails across the agent workforce.
Enterprises should start during design and prototyping, before agents move into broad production use. Manual reviews, scattered inventories, and team-level policy enforcement become harder to sustain as an agent workforce expands across teams and environments.
Enterprises should track owner, business purpose, identity, risk tier, model, prompts, tools, MCP servers, data sources, permissions, deployment environment, monitoring signals, audit logs, and review triggers.
The biggest risk is uncontrolled agent sprawl. Agents may gain unauthorized access, operate under inconsistent policies, drift after system changes, or take actions that teams cannot reconstruct after an incident.
The post AI agent governance at scale: from 5 agents to a 500-agent workforce appeared first on DataRobot.
Image copyright: Raphael Zufferey.
By Jennifer Chu
Loons, gulls, puffins, and petrels are some of the 100 species of birds that can both fly and swim. These diving birds can plunge in water to swim after prey, and then leap back into the air to fly away. Now, inspired by these naturally aquatic aviators, engineers at EPFL and MIT have designed a robot that can swim underwater, and flap out of the water to continue flying through air, much like diving birds.
The “flapping-wing aerial-aquatic vehicle,” or FAAV, weighs less than 300 grams and is designed to help scientists study the mechanics that enable diving birds to fly through air and water. The robot has a central body, or fuselage, two flexible, flapping wings, and a steerable tail. The wings and tail can be swapped out for different sizes. In experiments carried out in a water tank and a lake, the engineers identified combinations of wing size, flapping frequency, and tail angle that enable the robot to smoothly transition from swimming through water, to breaking through the surface, to flying through the air.
Their results, published in Science, can help scientists understand how diving birds adapt their flight mechanics to move through air and water, which have very different physical properties. The design could also launch a new class of aerial-aquatic drones and vehicles. The researchers envision such winged robots could be deployed to fly to and sample from aquatic regions that would otherwise be too dangerous for traditional ocean vessels to access.
Image copyright: Raphael Zufferey.
“Our dream vision is for oceanographers, marine biologists and coastal communities to launch this robot from a boat, or from shore, and it would fly close to the area of interest, such as an iceberg, a port facility or over a pod of whales,” says lead author and former EPFL researcher Raphael Zufferey, now an assistant professor of mechanical engineering at MIT. “It would dive into the water to take a measurement or collect a sample, and fly back to deliver the data at a fraction of the cost of traditional methods. Then it could go back out to dive for more.”
Zufferey began working on the robot as a postdoctoral fellow in the Laboratory of Intelligent Systems (LIS) and Biorobotics Lab (BioRob) in EPFL’s School of Engineering, under the supervision of respective lab heads and co-authors Dario Floreano and Auke Ijspeert. He completed the work at MIT, where he now leads the AURA Lab, which focuses on engineering bioinspired aerial and aquatic vehicles. The study also includes co-authors from Northwest Indian College (USA).
With bird biomechanics in mind, the team developed a robot with wings made of thin membranes coated with hydrophobic nanoparticles to help wick away water. The body contains a battery and a waterproof electric motor that drives a crankshaft, which in turn pumps the wings up and down at pre-set frequencies. The tail is motorized, enabling it to change its angle to help the robot fly up or dive down.
The researchers performed experiments first in a small water tank at EPFL, and then in Lake Geneva. They found that wing size (80 centimeters) and flexibility are key; the wings need to be flexible enough to minimize flapping amplitude in water, and firm enough to keep the robot aloft in the air. The robot could swim at speeds of almost one meter per second when it flapped with a frequency of around 5 hertz (five flaps per second), and fly at around 6 meters per second when flapping at a similar frequency. These speeds and flapping frequencies are similar to those of actual diving birds. To make the leap from water to air, the robot must be pitched at a relatively steep 70 degrees to keep its wingtips from touching the water’s surface.
Image copyright: Raphael Zufferey.
Interestingly, this combination of wing size, flap frequency, and tail pitch enabled the robot to swim underwater, launch off the surface, and fly without something that many diving birds require: feet. “If you look at birds, most birds need to paddle their feet at the surface to take off. And the question was, do we need the same for robots? And it turns out we don’t,” Zufferey says. “No one’s been able to fly out of the water with wings.”
Going forward, the team is improving the design of the wings to enable them to turn in addition to flapping up and down. They will also test the robot’s performance under turbulent conditions, such as swimming out of choppy waters, and flying through wind. Then, they hope to deploy the vehicle to help answer questions in ocean science.
Leaping out of the water: Aerial-aquatic locomotion with flapping wings, Raphael Zufferey, Simon L. Jeger, Moritz Hüsser, Fernando Ruiz, Anthony Lapsansky, Auke Ijspeert, Dario Floreano, Science (2026).
The previous post left you with a borrowed credential and a non-deterministic actor that a static grant cannot govern. The fix is to stop borrowing. Give the agent a stable, verifiable runtime principal you can authorize against, attribute actions to, and revoke on its own.
That sentence hides four requirements. Pull them apart.
A distinct principal. The agent is its own actor, not a human it impersonates and not a shared service account it hides inside. Its actions resolve to it.
Scoped permissions. The grant is narrower than any human’s, sized to the task, not to the person who launched it. Scope is the answer to the non-determinism problem from Part 1: you cannot predict every action, so you bound the space the agent can act in.
A clear owner. Every agent traces back to a person or team accountable for it. An identity with no owner is a liability with no name on it.
A kill switch. You can revoke the agent without touching anyone else’s credentials. Independent revocation is what makes the identity safe to hand out in the first place.
Miss any one of these and you are back in Part 1. The alternatives engineers reach for first each miss at least one.
| Approach | Actor model | Attribution | Scoping | Revocation | Where it breaks |
|---|---|---|---|---|---|
| Shared service account | One identity, many agents | None: all agents look identical | Coarse, shared by all | Revoke one, you revoke all | No way to tell agents apart or shut one off |
| Per-user impersonation | Agent borrows a human | Logs show the human, not the agent | Inherits the human’s full access | Rotating the key breaks the human | The Part 1 problem, by another name |
| Static secret | A long-lived key | Tied to a secret, not an actor | Whatever the secret was minted for | No rotation, no clean revocation | Secret leaks, lives forever, scopes nothing |
| First-class agent identity | A distinct principal | Actions resolve to the agent | Task-scoped, narrower than a human | Independent kill switch | Cost of running it as real infrastructure |
Table 1. The same four questions, asked of every option people try before they give the agent its own identity.
If the agent gets a stable runtime principal with scoped permissions and a kill switch, you have described workload identity. So is agent identity just workload identity with a new label?
This is a live debate, not a settled point, and the honest answer is: it depends. It depends on three invariants.
A one-to-one mapping. One agent corresponds to exactly one workload. When that holds, the workload’s identity is the agent’s identity.
A registry as the source of truth. Something authoritative records which agents exist and what they are. Without it, you cannot reason about the population of agents, only about individual processes.
Identity continuity. The identity survives restarts, pauses, and reschedules. The agent that comes back up is provably the same agent that went down.
When all three hold, agent identity collapses into workload identity. You attest the workload with something like SPIFFE or WIMSE and you authorize against it directly. No extra layer earns its place.
When they break, agent identity becomes a layer on top of workload identity. And they break often. Agents are bursty. They are ephemeral. They churn across workloads instead of pinning to one. They spawn sub-agents that have no workload of their own to attest. The one-to-one mapping dissolves, continuity gets hard, and the workload is no longer a faithful stand-in for the agent.
The publicly announced platforms show the layered pattern in production. Microsoft Entra Agent ID introduces a specialized principal that extends an existing directory, rather than reusing a plain workload identity. AWS Bedrock AgentCore exposes a stable agent identity that sits above a sandboxed workload, which can churn underneath without the agent’s identity churning with it.
Notice what both share. Each lives inside a single control plane and a single trust domain. One system issues the identity, governs it, and can see every hop the agent makes, because every hop happens on home turf. That is what makes the layered model tractable for these platforms.
Hold that observation. It is doing more work than it looks like, and it is the assumption that breaks in Part 4.
An agent identity is a stable runtime principal with its own scoped permissions, a clear owner, and an off switch. Whether that is plain workload identity or a layer above it is not a matter of taste. It depends on whether you can hold the one-to-one mapping, a registry as source of truth, and continuity across the agent’s life. Audit your own agents against those three invariants. Where they break is where you need the extra layer, and where most real fleets live.
You now have a single agent with an identity. Real systems are not single agents. A user calls an agent, the agent calls a tool, the tool calls another agent, and the identity has to survive every hop. The next post is about what happens to identity in that chain, and the protocols that either preserve it or destroy it.
The post What a first-class agent identity actually is, and whether it is just workload identity appeared first on DataRobot.