Functional copilots: build the place where the work happens

Session slides

Company after company, developers get one business function and are told to build an agent for it. Legal wants vendor contracts reviewed. HR wants headcount requests drafted. Finance wants to check spend before it reaches the CFO. IT wants access requests handled.

The upside is real: hours back on work that repeats every week. So is the catch. An agent that saves time but goes off the rails costs more than it saved.

This post walks through how we think about building these agents, which we call functional copilots: copilots built for one function and the people in it, working inside the software where that work already happens.

From answering questions to owning the work

Take a job most teams know: getting a vendor contract signed. With a chat assistant, you paste clauses in, ask about one playbook rule at a time, copy its text into Word, and chase three approvers yourself. By next week, nobody remembers what Security pushed back on. You still do the job. The assistant answers questions.

A functional copilot lives inside the matter. It reads the open contract itself, checks every playbook rule and cites each one, and drafts redlines in the review table for you to edit. It routes approvals by rule and waits for each approver. Nothing goes out until a person clicks send.

The copilot owns the workflow. People keep every decision.

You can see this pattern in the companies already doing it at scale. Cursor lives in its own editor. Harvey and Legora live inside Word. Abridge lives inside Epic. None of them is a chat box. And in 2026, more teams are skipping the plugin and rebuilding the workspace around the agent, so they own the UI, the data, and the approvals.

A method: from a role to a copilot in five steps

We built our demo, Open Harvey, a legal review workspace, around a simple story. Northstar Software needs Acme Cloud to sign the contract by Friday. Maya, senior counsel, reviews it. Three people approve: the General Counsel, the Head of Security, and the CFO. One contract, four teams, three approvers.

To get from that role to a working copilot, we follow five steps:

1. Research. Map how the work happens today: the role, the software it lives in, the jobs to be done and the key flows. For Maya, that meant email, Word with Track Changes, a deviations spreadsheet, and a written playbook.
2. Context and access. Map what the copilot can read and reach, from the open document out to org systems and people in Slack or Teams. Use the closest source that works, and gate every write.
3. Spec and build. Write a spec you approve, then build. With CopilotKit, four hooks connect the app to any agent over AG-UI: what it sees (useAgentContext), what it can do (useFrontendTool), what it shows (useComponent) and what waits for a person (useHumanInTheLoop).
4. Deploy. One Next.js app serves the UI and the runtime. Put the runtime route behind your auth, and keep the model key on the server.
5. Secure and govern. Six items get you to a safe pilot: an approval gate on every write, no open endpoint, secrets out of the code, a demo mode, a decision log, and stored threads. Production adds ten more, including SSO, roles, an audit trail, prompt-injection defenses, spend limits, and evals.

Each step is a skill you run in your coding agent, starting from one command: /functional-copilot.

The rule nobody wrote down

Here's where it gets interesting. In our story, the Head of Security sends Acme's contract back and asks for a SOC 2 Type II report and a pen-test summary. It's the fourth time Security has asked for the same thing, and the playbook still doesn't say it.

Because the send-back happened inside the app, the copilot could spot the pattern and propose a new rule, with the earlier send-backs as evidence. The General Counsel reviewed it and published it. That afternoon, a new order form arrived, and the copilot added the security request on its own. Nobody had to ask.

The model wasn't retrained. The new rule is a skill: an instruction a person can read, approve, version, and pin.

Learning from the full stack

Most of what an expert does never reaches the chat. Picture a support agent that refunds a $1,200 duplicate charge. By the usual definition, that trajectory is complete. But the user then opens Billing, reverses the refund, and issues an account credit instead. The right answer lives entirely in the half nobody captures.

That's why we're introducing CLiF: Continual Learning from Full-Stack Trajectories. CLiF layers what the user did in the product (clicks, edits, decisions) onto what the agent did, in one ordered stream over AG-UI. You label which trajectories are worth learning from, then turn them into product insights, skills, eval cases, and training data. The format is open, so you can export it and use it with any stack.

If you remember one thing

Building a functional copilot means building the environment where your users and agents work the task together. Build it with CopilotKit, and you learn from both: your users' actions and your agent's traces.

In our story, Acme signs on Friday. The copilot didn't replace anyone's judgment. It remembered it.

Start tonight

Everything above is in one public repo: github.com/jerelvelarde/functional-copilots. Copy skills/ into .claude/skills/ and run /functional-copilot. Two starters come with it: Open Harvey as a web app, and the same copilot running as an OpenBot coworker.

Pick one workflow that happens every week and ends in a person's approval. Start there.

Build yours with us

Want help building a functional copilot for your team? Book a call with an engineer, and we'll help you map the workflow and get it into production. Rolling it out across your company? Talk to our team.

We can't wait to see what you build. Follow CopilotKit on X for what's next, and join the CopilotKit and AG-UI Discord communities if you get stuck.

Open Harvey is an open-source CopilotKit demo, not affiliated with or endorsed by Harvey.