How I’m Using AI to Build Operational Agents Without Writing Code

jennMar 9, 2026

I’m a systems and computer engineering graduate with a concentration in databases (I graduated so long ago that I’m not even sure if the degree still exists under that name, and I doubt they still have “concentrations”).

Early in my career I spent time programming, although over the years my role shifted toward systems thinking: managing projects, designing processes, and running a company with my partners.

These days I don’t spend my time writing code. But that doesn’t mean I stopped thinking about systems or how software should work.

Recently, AI has unlocked something that used to be difficult: building operational agents without needing to write code myself.

That’s right. We’re creating agents that help us with our daily tasks: administration, marketing, and basic tedious processes that take time away from what really matters.

One of the first agents we created is Sakura, who helps us create landing pages in minutes just by giving basic instructions through Slack.

These are not experiments — they are actual tools we use inside the company.

Sakura agent example


The Problem I Wanted to Solve

For years, I kept running into the same issue.

There were dozens of small operational tasks that were too annoying to do manually, but never important enough to justify building a full system for them.

Examples like:

  • collecting invoices every month
  • generating landing pages quickly
  • organizing internal information
  • handling repetitive admin tasks

You either:

  • do it manually
  • try to find a SaaS tool that almost solves it
  • or ask developers to build something (and it never becomes a priority)

So these problems just sit there.


AI Changed the Equation

What changed recently is that AI allows you to define behavior before building the system.

Instead of starting with code, you start with instructions and logic.

And once that behavior is defined, you can connect it to an execution layer like Kanvas that runs the automation and connects it to real systems.

This means operators, not just developers, can start building useful automation.

In our case, we started experimenting with agents that operate directly through Slack.

Instead of opening a dashboard or writing scripts, we interact with them conversationally.

We now have a few internal agents helping with different operational tasks.

One of the first agents we created is Sakura, an agent that generates landing pages from simple instructions.

For example, we can send a Slack message describing:

  • the product
  • the audience
  • the goal of the page

And within minutes Sakura generates:

  • the page structure
  • copy
  • suggested sections

What used to take hours now takes minutes.


Jack — The Expense Collection Agent

My most recent agent is Jack, and I’m particularly excited about this one.

For the last 2–3 years I’ve been trying to solve a recurring problem: collecting and organizing monthly expense invoices.

Every solution I tried was either too rigid, too manual, or required constant follow-up.

Jack now handles that process.

He collects the invoices, organizes them, and stores them in the correct place in Google Drive.

This is exactly the type of operational task that is perfect for an AI agent:

  • small
  • repetitive
  • easy to describe logically

The Prompt

This is the prompt I used to create Jack.

The interesting part is that the prompt itself is not the system.

It simply defines how the agent should behave.

For example:

  • what its role is
  • what inputs it should expect
  • how it should process them
  • where outputs should go

Once that behavior is defined, it runs through Kanvas, which acts as the operational layer connecting the agent’s logic to real systems and APIs.

Agent architecture

Caption: Agents defined through prompts, executed through Kanvas, and connected to real operational systems.


The Real Shift

The most interesting shift here is not the technology.

It’s who can now build automation.

For a long time, automation required engineering resources.

Now operators — people who understand the workflows and the problems — can define solutions themselves.

Developers are still essential for building robust systems, but the barrier to experimenting with operational automation is dramatically lower.

And that’s where a lot of interesting things are starting to happen.


The Real Bottleneck

We’re entering a moment where the main limitation is no longer code.

It’s how clearly you understand the problem you want to solve.

If you can describe the workflow clearly enough, you can often build an agent to handle it.

Which means the people closest to operations may soon become the most powerful builders in the organization.

And that shift may change who the real builders inside organizations are.

Sign up to receive a weekly recap

Get the latest insights from our team delivered straight to your inbox.

Contact us on WhatsApp