Sign in

News & Blog

Research, engineering, and ideas from ACTAVA.

Videos

117 videos

ACTAVA | Agentic Workforce | Agent Workspace Steps

The agent that does everything is the one nobody can fix. There is always a temptation to let one good agent absorb the next task, and the one after that. It ends the same way every time. One agent doing five jobs is not five times as useful. It's five times harder to change. Diagnosis suffers first. When it fails, which of the five jobs failed? A narrow agent tells you by failing narrowly. Permissions suffer next, because five jobs means the union of five tool sets. Every job ends up running with access to every other job. And then change stops. Improving one behavior risks the other four, and eventually nobody touches it at all. The alternative is visible once you stop looking for the clever agent. Look at these as separate steps instead, each doing a job you could describe in a sentence. The pipeline is what joins them, and that's where the coordination lives — not inside any one of them. Small agents are also the ones that show up in a catalog twice because a narrow job is one somebody else also has. Real work stays split the same way: each step a job somebody could describe out loud. And narrow jobs are the ones that turn up in a library, because somebody else has that job too. Split it while splitting is still cheap. That window closes quietly. Small agents fail in ways you can find.

ACTAVA | Agentic Workforce | Agent Memory, Prompts, & Plans

One is what the agent is told. The other is what it carries. When an agent keeps forgetting a rule, the instinct is to say it again, louder, in the prompt. That is not what memory is for. Prompt, plan, and memory look interchangeable right up until you have to change one of them six months later. The prompt is who the agent is and what it's for. Changing it changes the agent's whole character, which is exactly why nobody wants to touch it. The plan is the steps for this job. Specific, ordered, and the right home for anything procedural. Memory is for standing rules that outlive any single run. Always verify opt-out status. Never send without approval. Short, absolute, and editable on their own. You can see the separation hold up in practice. Memory entries are rules that belong to the agent rather than to whoever happened to type the last message. Skills and memories sit side by side, so what it knows and what it can do are visible in one place. At runtime, it pulls in what it needs, and the rule travels with the agent rather than the prompt. The person asking doesn't restate the rules, because they shouldn't have to. And the result reflects rules nobody typed into that message, which is the whole point of putting them somewhere else. If you find yourself repeating a rule in a prompt, it was never a prompt. It was a memory.

ACTAVA | Agentic Workforce | Agent Blueprints

An agent you cannot audit is a vendor promise with a text box. You would not deploy a service nobody on your team had read. Agents get an exemption they have not earned. Auditability here isn't a compliance chore. It's the only way to know what you actually built, or bought. You want the inventory. Which tools, which external servers, how many steps and tasks. A list, not an adjective. You want the rules it operates under, stated as policy rather than buried in paragraph four of a prompt. And you want to know where it hands back to a person. If there's no such point anywhere, that is a finding, not a feature. That's what a blueprint is for: what the agent is for, what it can reach, what it's allowed to do. The same view sits inside the builder, because the thing you review should be the thing that runs. The listing carries it forward, so nobody has to open the internals to know what they're picking up. Whether generated or hand-built, it has to be readable, because otherwise the review is theatre. And a catalog only works if you can read the thing you're about to pick up. Impressive is easy to demo. Auditable is what survives the second meeting.

ACTAVA | Use Cases | Care Management (Post-Discharge Follow-Up)

Told no twice, it takes the no both times — and still says the thing that matters. If you run a discharge program, you already know which call gets skipped. Forty-eight hours after discharge, someone should check that the instructions were understood. Discharge instructions are given once to someone who has just been discharged, and follow-up is the first thing to fall off a busy list. So this is one end-to-end journey rather than a feature tour: configure the agent, hear the call, then look at what the call left behind. Configuration first, because the shape matters. A voice agent is configured as a voice agent, not a chat agent with a phone bolted on — a model, a voice, a language, and a clinical preset. You set which direction it works in; this one places calls rather than waiting for them. Then you write down who it is: a courteous outbound caller representing the care team, warm, respectful of the person's time. And one line to hold it to a minute later — it gracefully accepts no without pushing. Then the call. Both voices are synthetic, and the conversation is written for this demo rather than recorded, which the cut says out loud before it plays. Watch for the two moments the patient pushes back: they're on their way out and ask whether this will take long, and later they decline the offer of appointment details. The agent takes both the first time. No second attempt, no working around the answer. It confirms who it has, asks one thing at a time, hands the request to the care team rather than promising anything itself, and names the one condition under which the patient should stop waiting and call a person. Then the half that decides whether any of this survives a review. Every call it has made is kept — its duration, per-service cost, and which agent ran it — in a list you can filter, rather than a log somebody has to go and find. Open one, and the cost splits across the model, the speech recognition, the speech itself, and the telephony. And then the transcript panel, which reads: "HIPAA mode enabled; transcript not stored for compliance." On a demo, that looks like a gap. In this line of work, it is the setting working — and the reason the thing is deployable at all. None of this replaces the clinician. It makes the call that wasn't being made, and it leaves behind something you can stand behind.

ACTAVA | Agentic Workforce | Agents You Build by Describing the Work

The person who knows the job is rarely the person who knows the form. The people who understand a workflow best are usually the least equipped to fill in a configuration form about it. Both routes produce an agent. Only one of them can be done by the person who actually knows how the work is supposed to go. The expert is not the builder. A nurse can describe a handoff perfectly and have no view whatsoever on model tiers or tool schemas. A draft beats a blank form. Reviewing a generated configuration is a far easier job than authoring one, and disagreement surfaces immediately rather than three weeks in. And review is still required. Generated does not mean correct. The point is moving the human effort from typing to judging. You can watch that play out. You describe the work in plain language, and that's the input. What comes back is configuration you can read, correct, and disagree with before anything runs. The description was the fast part; reviewing what it produced is where the judgment goes. It starts from a blank field rather than a form with forty settings. And the shape holds up under harder work, too: describe the workflow, then review what came back. Say what the work is. Review what comes back. The form was never the hard part. Knowing what the work is was the hard part.

ACTAVA | Agentic Workforce | Agent Connectors (Tools, APIs, MCPs)

Adding a tool is a security decision wearing a convenience costume. Adding a tool to an agent feels like adding a feature. It's closer to granting an account access to a system. The tool list is the blast radius, and it deserves the scrutiny you'd give a service account. It rarely gets it. Ask what it can reach. Read a calendar, or write to a record? Draft an email, or send one? The verb is the entire risk. Ask on whose behalf it acts. Agent credentials, or the user's? One is auditable to a person. The other is a shared account with nobody's name on it. And ask what happens if it's wrong. A wrong search wastes a second. A wrong send cannot be recalled. Reversibility determines where the gate goes. Those questions have a home in the product. Every tool attached to an agent is a door you're opening, and the blueprint lists them together where you can see them. Connectors are the same question one level up: what is this allowed to reach? Access is set per agent, so the answer can be different for each one, which is the whole point. Keys are the same conversation with the volume turned up. And the store is where it becomes a habit, because picking a tool grants permission every time. Ask what it can reach, not what it can do. Features get added. Permissions get granted. Tools are the second thing pretending to be the first.

ACTAVA | Agentic Workforce | Agents That Follow a Plan, Not a Paragraph

Prose describes intent. A plan is something you can check. Most agents start life as a wall of prose. It reads well, and it hides every decision the agent is actually going to make. When written as ordered steps rather than paragraphs, the same instruction changes what everyone downstream can do with it. It becomes reviewable. A colleague reads eight numbered steps and says step four is wrong. Nobody can do that to a page of prose. It becomes addressable. You can mark one step for approval or retry it. There is no middle of a paragraph to mark. And it survives editing, because changing step six leaves the rest of it intact. Rewriting prose quietly changes things nobody noticed. You can see the difference in the product. The work gets defined as a structure rather than a paragraph of hopeful instructions, broken into steps you can read in order, which means you can argue with step three without rewriting the whole thing. Before it does the work, the agent shows you the plan it intends to follow. And a plan you can see as a pipeline is a plan you can change one piece at a time. Which matters, because the ask was one sentence and the work is considerably more than that. So write the paragraph if it helps you think. Then turn it into steps before anyone has to trust it. A plan is reviewable. A paragraph is a hope.

ACTAVA | Agentic Workforce | Agent Versioning

A prompt you edited is not something you can roll back. Here's a question worth sitting with. If someone changed your agent yesterday and it got worse, what exactly do you roll back to? Editing a prompt feels like editing a document. It behaves like deploying to production, except with no tag, no diff, and no way back. Three different states get collapsed into one when all you have is a prompt box. There's the draft, which is where the work happens. Every save overwrites the last one, so nobody can tell you what it said on Tuesday, or why. There's the version: a snapshot with a note attached saying what changed. That's the moment it stops being something someone edited and starts being something you can point at. And there's promotion, meaning which version actually runs by default. Keeping that separate from the draft is what makes improving an agent and changing what serves people two different acts. You can see all three in the product. The draft contains the system prompt, the plan, and the tasks, but it doesn't record what it said yesterday. Snapshotting it creates a version, and the box asking what changed is the part that matters, because it's the only place the reason survives. Then you have a history: draft and version one side by side, each with who saved it and when, where you can view either, compare them, or restore an old one straight back into the draft. Edit the draft. Ship the version. The question isn't whether you version your agents. It's whether you find out you needed to before or after the rollback you can't perform.

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.