Adaptive Work Agent

Inspiration

The idea started much smaller.

We were thinking about how difficult it can be to use an unfamiliar application. Our initial idea was to have a cursor that could recognize what you were hovering over, explain what the feature does, tell you how to use it, and guide you to the next step.

That led to a broader question: what if learning could happen inside the software while you are actually doing the work, instead of being something that happens before it?

We then started thinking about how this could work in an enterprise environment, and Freshworks was a natural fit. Enterprise workflows can be complicated, and when an employee gets stuck, the usual options are documentation, asking a colleague, raising a ticket, or simply trying to figure it out themselves.

The problem isn't always that people don't know something. Often, it is that the people who do know it don't have the time to keep explaining the same thing.

That changed our original idea from a cursor that explains software into a bigger question: what if an AI agent could understand the task and decide whether it should do the work, teach the employee to do it, or ask a human for help?

That became Adaptive Work Agent.

What it does

Adaptive Work Agent is an AI work agent that makes this decision for every task:

• EXECUTE — when the task is well understood, low risk, and within the appropriate authority.
• TEACH — when the task is safe but unfamiliar. The employee performs the work while the agent provides contextual guidance.
• ESCALATE — when the task is risky, ambiguous, or outside the employee's authority. The agent stops and brings in a human.

The important part is that the decision isn't fixed. As an employee successfully completes a workflow, the agent can reduce the amount of guidance it provides. But if the workflow or policy changes, previous experience may no longer be enough, so the system can increase guidance again.

We call this Work Readiness.

The basic loop is:

Task → Context + Risk → (Execute / Teach / Escalate) → Verify → Learn → Adapt

The idea is simple: autonomy should be earned, not assumed.

How we built it

We wanted the prototype to demonstrate one real workflow rather than build a generic chatbot.

We chose a refund workflow inside Freshworks.

Freshworks MCP provides the task context and the actions the agent can take. The decision layer evaluates factors such as the task, risk, employee authority, workflow state, and Work Readiness before choosing one of the three modes.

For Teach, the original cursor idea evolved into contextual guidance inside the workflow. Instead of sending an employee away to read documentation, the agent explains what to do and why, while the employee performs the step. We use ElevenLabs to make this interaction voice-based.

For Escalate, we use a concrete example: a ₹25,000 refund where the employee's authority limit is ₹10,000. The agent doesn't simply make the decision because it has enough information to process the refund. It recognizes that the decision belongs to someone else, reaches the manager through the voice escalation flow, explains the situation, and captures the approval before the workflow continues.

The escalation architecture connects the workflow state to ElevenLabs' conversational agent and returns the structured outcome to the workflow through MCP.

We deliberately kept some enterprise infrastructure, such as a production HR-directory lookup, outside the live prototype. The goal was to demonstrate the core decision and interaction rather than pretend that a complete enterprise deployment could be built in a hackathon.

Challenges we ran into

Designing Work Readiness so it reflects real competency shifts, rather than acting as a fixed label, was harder than expected. A policy change needed to be able to reset even an expert's score to zero, since past performance shouldn't count for a workflow that no longer exists in the same form.

Making voice a functional part of the workflow, rather than a decorative layer, was another challenge. It wasn't enough for the agent to speak — the spoken response from a manager during escalation had to be parsed back into a structured, auditable action through MCP, not just logged as text.

We also had to scope honestly. It would have been easy to overbuild parts of the demo, like full natural-language approval parsing or a live HR-directory lookup, and end up with something fragile. Instead we focused the live prototype on demonstrating the core decision — Execute, Teach, or Escalate — clearly and reliably, and kept a few pieces of enterprise infrastructure outside the live build.

Accomplishments that we're proud of

We're proud that the prototype demonstrates the actual decision, not just three separate features. One workflow, one agent, three different real responses depending on who is doing the task and what it requires.

We're also proud of how voice ended up serving two distinct, functional purposes — teaching someone in the flow of their work, and getting a real human decision when the agent recognized a task wasn't its call to make — instead of being added purely for demo effect.

Finally, we're proud that Work Readiness behaves the way we wanted it to: it isn't a static role or title, it moves with evidence — resetting on policy change, dropping with friction, and climbing with clean completions.

What we learned

The biggest thing we learned from building this was that the interesting question with agentic AI isn't always "Can the AI do this?" It is increasingly "When should the AI do this?"

At first, we were thinking mainly about helping someone learn how to use software. Building the project made us realize that learning is only one part of the problem. The harder problem is deciding where the boundary between AI, employee, and expert should be.

We also realized that autonomy cannot simply increase because an agent has been successful before. A workflow can change. A policy can change. Even a task that was familiar yesterday can become unfamiliar tomorrow.

That is why our system doesn't treat autonomy as a permanent setting. It uses evidence from completed work, guidance, overrides, and workflow changes to adapt the level of autonomy.

Another thing we learned was that voice is most useful when it has a reason to exist. We didn't want to add voice just because it makes an AI demo look impressive. In our case, it serves two specific purposes: teaching someone while they work and getting a human decision when the agent should not make one itself.

Most importantly, the project changed how we think about AI agents. We don't think the goal should always be to make agents more autonomous. Sometimes the better system is one that knows when not to act.

What's next for Adaptive Work Agent

The next step is wiring up the parts we deliberately kept outside the live prototype, starting with a real Freshworks integration through Agent Studio and a proper HR-directory lookup for escalation contacts, instead of a mocked one.

We also want to move from a scoped yes/no approval branch to fuller natural-language intent parsing during Escalate calls, so the agent can handle a wider range of real manager responses, not just clear approvals or denials.

Beyond the refund workflow, we want to test Work Readiness and the Execute/Teach/Escalate decision across other enterprise workflows to see how well the same core loop generalizes — since the underlying idea, that autonomy should be earned and re-evaluated rather than fixed, isn't specific to refunds or even to Freshworks.

Built With

• claude
• conversationalai
• elevenlabs
• figmamake
• freshworksmcp
• modelcontextprotocol
• multi-agentsystems
• promptengineering
• voiceai