Sign in

News & Blog

Research, engineering, and ideas from Actava.ai.

Videos

117 videos

VideosWatch video

ACTAVA | Agentic Workforce | Agents That Humans Must Approve

Some work an agent does should never reach the world without a person saying yes. Putting a human in the loop sounds like a good idea. It isn't free, and past a certain point it stops buying you safety at all. A gate converts speed into accountability. That's a good trade exactly once per decision that deserves it, and a bad one everywhere else. The real cost isn't the click. It's the wait. Work sits until someone looks, and whoever happens to be on leave becomes a dependency no one wrote down. And there's a worse failure than slowness. Gate everything, and approvals turn into rubber stamps. A reviewer clearing forty items a day is reading none of them. The gate still exists on the org chart, and it has quietly stopped doing anything at all. So the question isn't whether to have approvals. It's where they earn their cost. Put the gate on the irreversible step: sending, submitting, paying, publishing. Let the agent draft as freely as it likes, and stop it at the door that only opens one way. Done properly, that gate is a real control rather than a promise. It's enforced by the system rather than by a prompt asking a model to be careful. It names who decides, and it doesn't wait forever on someone who's away. And it leaves a record, because a gate you cannot audit is a gate you cannot trust. The rejections are the evidence that the review was real. A gate on everything is theatre. A gate on the thing you can't undo is control.

Watch ↗

VideosWatch video

ACTAVA | Agentic Workforce | Agent Schedules

Say when in plain English. It writes the cron and shows you the next five runs before you commit. The best agent run is the one nobody had to remember to start. But scheduling is where automation quietly goes wrong. Somebody writes a cron expression, nobody else can read it, and six weeks later a report has been firing on Sundays. So the interesting part of this surface isn't that it schedules. It's that it reads the schedule back to you. Each schedule is an agent, a prompt, a cadence, and a next run, executed through the external API so it fires whether or not anybody is logged in. Composing one starts with picking the agent, and notice what the picker offers: agents that are actually live, not drafts. That quietly enforces the promote-then-deploy lifecycle and stops a half-finished draft from being wired to a recurring trigger. Then an API key with write permission, and the prompt it should run. Summarize what was completed overnight, how many were rejected at approval, what it cost, and put it in a one-page PDF for the operations lead. Then the cadence, and this is the part worth watching. Take a common one from Quick Picks, write raw cron by hand, or just say it. Every weekday at 7am. It turns that into a cron expression, tells you how confident it is that it understood, renders the plain reading back, and then does the thing that actually matters: it lists the next five times this will fire and asks you to check them. Nobody can eyeball a cron string. Everybody can spot a wrong day in a list of dates. That last step is how you catch a schedule that says Sunday when you meant Monday, before it costs you six weeks. An agent running at seven every weekday morning, on a schedule somebody read back in plain English before trusting it. That's the work happening without the meeting about the work.

Watch ↗

VideosWatch video

ACTAVA | Agentic Workforce | Agent Benchmarking Evidence Scoring

"It seems better" is not a result. Somebody changes an agent, tries it twice, and says it feels better. That's not a result. That's a mood. The gap between vibes and evidence is smaller than people think. Three things turn a hunch into something provable, and none of them need a data science team. A fixed set of tasks. The same ones every time. If the inputs change between runs, you're comparing two different questions and calling it progress. A rubric for each task, written down before the run. Grade after you've seen the answer, and you're grading nothing. And a diff, not a number. Compare two runs rather than reading one. An overall score moving tells you almost nothing on its own. Which metric moved, and which specific row, is the finding. Because the goal was never a number that looks good. It was a row you can open, read, and fix.

Watch ↗

VideosWatch video

ACTAVA | Agentic Workforce | Agents with Autonomy vs Approvals

Anything running unattended needs somewhere you can watch it. Every argument for letting agents run unattended quietly assumes you'd notice if one went wrong. Would you? Autonomy isn't really a property of the agent. It's a property of the system watching it, and it's earned in a specific order. First, what is running. One list of everything in flight and what each thing is waiting on. If that only exists in individual people's browser tabs, it doesn't exist. Then, what it cost. Duration and spend per run. Not for the finance team, but because a run that suddenly costs triple tells you something has changed. And then the one nobody builds: what you refused. The rejections. A history containing only successes means either nothing is being reviewed, or nothing is being caught. Earn those three, and unattended stops being a leap of faith. Skip them, and it always was one.

Watch ↗

VideosWatch video

ACTAVA | Agentic Workforce | Agents that Stop when Gated

Approval is not free, and it is not the same as safety. Putting a human in the loop sounds like a good idea. It isn't free, and past a certain point it stops buying you safety at all. A gate converts speed into accountability, which is a good trade exactly once per decision that deserves it, and a bad one everywhere else. The real cost isn't the click. It's the wait. Work sits until someone looks, and whoever happens to be on leave becomes a dependency no one wrote down. And there's a worse failure than slowness. Gate everything, and approvals turn into rubber stamps. A reviewer clearing forty items a day is reading none of them. The gate is still there on the org chart, and it has stopped doing anything. So put the gate on the irreversible step. Sending. Submitting. Paying. Publishing. Let the agent draft as freely as it likes, and stop it at the door that only opens one way. A gate on everything is theatre. A gate on the thing you can't undo is control.

Watch ↗

VideosWatch video

ACTAVA | Agentic Workforce | Agent Workspace Sources & Fan-Out

Point a workspace at a source, then run the same governed workflow across every row in it. Most agent work is demonstrated one input at a time. Real operations don't arrive one at a time. A cohort, a worklist, a queue of referrals, a month of claims: the same workflow, run against hundreds of inputs, where the interesting part is which ones failed and what you do about them. Fan-out is how a workspace handles that. You give the agent team a source, and the pipeline executes at scale by running a single workflow in parallel across many inputs rather than asking someone to paste them in one by one. Progress lands in a unified grid, so you watch the whole batch rather than a single run. And when something fails, you retry only what failed, without re-running the work that already succeeded. On a large batch that distinction is the difference between a rerun you can afford and one you can't. Governance doesn't loosen just because the volume went up. Every run in the batch is still metered, still attributable, and still subject to the same approval gates and audit trail as a single run, which is what makes scale safe rather than merely fast.

Watch ↗

VideosWatch video

ACTAVA | Agentic Workforce | Agent Workforce Library

Take an agent someone has already built, read it end-to-end, and make it yours in one click. Here's the fastest way to get an agent doing real work: don't build one. The hard part of starting was never writing a prompt. It's knowing what a good agent for this job looks like, and someone has already answered that. Agent Workforce is a catalog of existing agents, grouped by the work they perform and tagged with the roles that use them. Patient services. Care managers. Credentialing specialists. There is real depth behind it, with twenty-two agents for value-based care, eight for payer operations, and nine for behavioral health, and you can filter by the persona you are building for or by the challenge you are trying to solve. Say you're closing HEDIS and Stars gaps. A listing for a chronic disease management outreach agent tells you who it's for and the shape of the work it does: identify the cohort, segment it by language and channel, design the touch sequence, execute it, then triage every response and route each one to the right next action. Here is the part that matters most. Before you take it, you get to see it all. Every listing publishes the same blueprint view you get for agents you built yourself: the tool inventory, the MCP servers it calls, the step and task counts, and the rules it operates under. Fourteen tools. Five MCP servers. Four steps, thirty-one tasks, five rules. An analytics server for census and quality measures, prior-authorization and payer-directory lookups, and literature search. Reuse is only safe if you can audit what you are reusing, and you are not buying a black box with a price tag. You read the whole thing first. Then it's one button. Add to Agent Studio produces a real agent within your organization, not a link or a subscription. It arrives at version one, already promoted, with its full system prompt and its tools wired, carrying three operating rules as memory: always verify opt-out status before contacting anyone, include full context whenever it escalates to a care coordinator, and log every attempt for HIPAA auditing. It arrived knowing how to behave. From there, it's an ordinary agent you own. Rewrite the prompt, swap the tools, add your own approval gate, cut a new version. Everything downstream works exactly as it does for an agent you wrote. You just started from something that already worked.

Watch ↗

VideosWatch video

ACTAVA | Agentic Workforce | Agent Studio

The whole loop: build, visualize, version, promote, then operate an agent like software. Most agent demos stop at the moment the prompt works. The interesting part starts after that, when someone else has to review it, when it changes, and when a business has to know what is running and what it costs. This follows one agent, a discharge follow-up coordinator, through that entire loop. It starts in the studio, as a draft. A system prompt with real responsibilities, a plan broken into steps, eight ordered tasks, and a memory the agent carries with it, which in this case says patient-facing communication needs explicit named human approval. Nothing is live yet. A wall of configuration is hard to check, so the platform draws it. One click renders the agent's blueprint: the trigger that starts it, the tools it can reach grouped by system, the execution plan down the middle, the output at the end, and its operating principles on the right, rendered as policy. Always cite the source document. Never send a Gmail message directly. Never assume a risk tier. Guardrails appear as guardrails. You can read the whole thing in about ten seconds and hand it to someone who doesn't write code. Then the vocabulary that makes an agent reviewable. Each save updates the draft. Creating a version snapshots it, with a note describing what changed so the next person knows why. Promoting a version makes it what runs by default. Version history keeps the draft and each version side by side with who saved them and when, and you can view either, compare them, or restore an old one straight back into the draft. That is what turns an agent from something one person edits into something a team can review, roll back, and account for. Worth being precise here: promoting and deploying are two different steps. A promoted version is what runs by default, and it is still one switch away from serving end users. Then the half most demos never show. The Agent Dashboard separates which agent versions are live for end users from what is still in development, each row carrying its version, run count, success rate, and owner, so nobody has to ask which agent is actually running. And because agents cost money, a usage view splits consumption by workload type, by project, by person, and by model. That is the operating half of the lifecycle, and it is where a pilot either earns its next quarter or doesn't. Build it. See it. Version it. Promote it. Then watch what it does, and what it costs. That's not a prompt in a notebook. That's an agent you can run a business on.

Watch ↗

VideosWatch video

ACTAVA | Agentic Workforce | Agent Benchmarking (part 2)

Let a meta-agent write your agent's test set, then score every change against it. You shipped an agent that touches patient care. Then somebody edited a prompt. Does it still refuse the things it is meant to refuse? An agent's behavior is not fixed. Someone edits a prompt, swaps a tool, bumps a version, and the safety properties you were relying on may or may not still hold. Guessing isn't an answer. Benchmarking is how you find out instead of hoping. The part that makes it practical is that you don't write the tests. A meta-agent reads the target agent's own configuration, tools, and capabilities, and synthesizes an evaluation set with rubrics. You supply the intent. In this worked example, a discharge follow-up coordinator: synthetic data only and no PHI; anything outside the thirty-day window must be refused rather than drafted; every clinical fact must cite its source; and nothing patient-facing gets submitted without a named human approving it. Because the tests derive from the agent under test, they cover what it can actually do rather than what you remembered to write down. A couple of minutes later, the benchmark exists. Thirty-two rows, bound to the agent it was written for, and stamped with the version of the meta-agent that wrote it. It lands in your datasets with six columns you can see, and six more the platform derives, including decision points, testing path, and suggested tools. Then you read it, because a test set you cannot read is a test set you cannot trust. The row viewer shows all thirty-two generated cases, normal ones alongside counterfactuals. The counterfactuals are the hard cases, built specifically to break the rules you just named. Every row carries its own rubric stating what counts as a pass and what counts as a fail. And there is no patient data anywhere: every reference is synthetic, invented for the test. Then you run it. An experiment binds one dataset to one agent version, scores it, and keeps runs as history with an overall score and a per-metric breakdown showing which rows passed and which failed. That is the whole point. The score is attached to the version, so when somebody changes a prompt, you can see whether it moved, and a failure is a specific row for a specific reason that you can go and look at. Tests your agent writes for itself. Hard cases you'd never have thought to write. And a score that moves when your agent does. That's how you change an agent without crossing your fingers.

Watch ↗

See what ACTAVA can do for you

Bring one workflow your team still runs by hand. We'll show you the agent that runs it.