From No-Code to External APIs: A Practical Playbook for Your First Rovo Agent

[#1]

Rovo comes with powerful built-in agents, but most teams don’t live in an Atlassian-only world. HR data might be in Personio, time tracking in MOCO, documentation in Confluence… and suddenly everyone is juggling browser tabs just to answer simple questions.

So the natural question becomes:

Can we get Rovo to talk to those external tools, instead of copy-pasting data around all day?

That’s what we set out to explore.

We started with no-code agents in Rovo Studio to support HR and time-tracking workflows with data from Personio and MOCO. Later, we built MOCO-Buddy – a Forge-based Rovo agent that talks directly to MOCO so project data and logged hours are available right inside Confluence.

This article is a distilled version of that journey: not a shiny “success story”, but a practical playbook you can follow if you’re thinking about your own first external Rovo agent.

1. Don’t start with a toy use case

We didn’t begin with a “hello world” example. The goal was to pick something that was:

• Real enough to show whether Rovo + Forge actually helps.

• Small enough to fit into a four-week sprint and ship something the team could use.

In our case, that meant:

• Pulling HR and time-tracking data into a conversational interface.

• Making it possible to ask natural questions like “who’s responsible for this person?” or “how are hours distributed?” without leaving Confluence.

Starting from a real pain point kept us honest. If the agent didn’t help with daily work, it wasn’t a win, no matter how clever the implementation looked.

2. Let Rovo Studio carry the first 80%

The first version of the solution lived entirely in Rovo Studio as a no-code agent.

That agent could:

• Answer org questions, like “who reports to whom?”

• Pull absence data from Personio.

• Talk to MOCO to analyze logged hours.

• Produce visual summaries, for example charts showing how workplaces are distributed.

The interesting bit was how much of this could be driven by non-developers:

• Prompt instructions were written and refined directly in Rovo Studio.

• Relevant Confluence spaces were attached as context.

• Actions – including custom ones – were picked and wired up in the UI.

Behind the scenes, this was powered by custom Forge actions acting as connectors to external systems. They handled authentication, talked to the APIs, cleaned up the responses and handed data back in a form Rovo could work with. Because these actions are reusable, you build them once and use them across different agents.

Developers focus on the integrations; business users focus on the workflows.

3. When that’s not enough: move into Forge (without losing no-code speed)

At some point, the no-code + shared actions setup hits its limits. That’s when MOCO-Buddy became a Forge-based Rovo agent of its own.

The evolution happened in three stages:

First, the straightforward version.
Each MOCO API endpoint was wrapped in its own function. The agent called those functions to fetch data into Confluence. It worked, but it felt clunky and didn’t scale well. Every new use case wanted yet another function.

Then, the “aha” moment: a universal fetch function.
Instead of writing one function per endpoint, the implementation pivoted to a single, more general function. The agent was given relevant pieces of MOCO’s API documentation and learned to choose endpoints, use the right paths, and interpret responses well enough to answer queries. That combination (a universal fetch function plus API docs) turned out to be much more flexible than a pile of one-off endpoint functions.

Finally, treating the prompt as a real component.
One of the biggest practical lessons was how much the prompt matters. To iterate quickly, the Forge function was exposed as a no-code action and plugged into a no-code agent in Rovo Studio. Prompt tweaks could happen there, without redeploying the app every time. Once the behavior was reliable, that refined prompt flowed back into the Forge app itself. This loop – Forge for logic, no-code agent for fast prompt iteration – shortened development cycles significantly.

4. Know what Rovo is great at (and where reality bites)

After several rounds of testing, a pattern emerged.

On the plus side:

• A universal fetch function backed by API documentation is a powerful way to talk to external systems.

• The combination of no-code agent + Forge function is ideal for fast iteration on prompts and configuration.

• With the right setup, Rovo can genuinely integrate external SaaS tools into everyday work, not just summarize what’s already in Atlassian products.

But there were also hard limits you should be aware of before you start:

• There’s no contextual memory between interactions. Details from one API response don’t carry over to the next question; the agent has to rediscover them each time.

• Response times can be slow, especially when external calls are involved.

• It is not plug-and-play. Getting useful results required a fair amount of iteration. Early versions weren’t good enough until the essential system prompt and configuration were tightened up.

• The quality of the prompt makes a huge difference. Vague instructions lead to vague behavior.

None of this is a deal-breaker, but it’s better to go in with eyes open, especially if you need the agent to answer questions for real users, not just in a demo.

5. When you hit a wall, go hybrid

One surprise showed up at the integration boundary between Forge and no-code features.

In No-Code Studio, you get convenient actions such as “Page Create” and “Issue Create”. Those don’t automatically exist inside Forge apps; if a Forge-based agent should create Confluence pages, it has to do so via the appropriate APIs.

The workaround was a hybrid setup:

• A no-code agent remains the main entry point for users.

• Forge functions do the heavy lifting of talking to MOCO and other external systems.

• No-code actions handle things like creating pages or issues as the final step of the workflow.

It isn’t the most elegant architecture in the world, but for more complex workflows it turned out to be a practical way to combine the best of both sides: external data through Forge, and Atlassian-native actions through no-code.

Want to see this in action and ask your own questions?

If all of this has you thinking about your own stack and use cases, a written playbook can only take you so far.

We’re also hosting a live webinar where we’ll dive into this topic, walk through how to approach external Rovo agents in practice, and leave time for questions from the audience. If you’re experimenting with Rovo, Forge, or external APIs and want to sanity-check your approach, it’s a good place to do it.

👉 Register for the webinar here

If you’re reading this later, reach out to me for a recording and more information.