README

$ whoami
> Robert Ross

I build software. I have for a long time now. Some of it was good. Some of it bad. You’ve likely used some of it, whether you knew it or not. I care about reliability, performance, and API ergonomics.

I love building things for developers.

The Runtime Problem

To build an agent, it’s “just a loop” that runs on a server, calls a tool, then sends the result back to the LLM chat completions API. No big deal.

That’s what I thought when I started to build AI agents, at least.

But I was wrong. Super wrong, even. I ended up having to build compaction, tool approvals, context management, and a mixture of other things to get my assistant to execute my objective with a sense of durability. It was the most expensive “Hello World” I’ve ever built in my career.

But I had a blast doing it.

But it also didn’t move the bottom line for the business.

And the agent itself felt like drawing the rest of an owl.

Building a runtime for all

The idea of an agent runtime has lived in my head rent free after deploying several agentic features. Everywhere I look now, I see a new agent from a company. I see opportunities for autonomous agents everywhere, too. Agents are the ultimate augmentation of humans if built well.

And I believe there’s a place in this world for an agent runtime to exist as a service.

So I set off to build it. You found it. It’s called Cadenya. It comes from the word “caddie” from the world of golf. I don’t golf. But the name resonated.

And the domain was available.

Primitives

Caddie: From 1730 as “person who runs errands;”

Cadenya is modeled to support three major primitives:

1. Tool Sets (and their tools)
2. Agents (and their variants)
3. Memory Layers (and their entries)

The amalgamation of these primitives combines to support Objectives. An objective is something you assign to your agents. Your agents load the tools you’ve given them. And they will attempt to conquer a submission like “What is the status project Caddyshack after the last week of work?”

Objectives can be used to answer questions from users, research competition, summarize inboxes, etc. The core intent of the objectives data model was to make them generic. For you, the developer, to inject the creative ideas.

Runtime as a Service

Cadenya handles running your agent’s loop, performing tool calls, and more. Messages in your agent’s conversation are persisted, tool calls have analytics, and all of it is exposed via an API with SDKs in several languages.

One important note though: Tool calls are over HTTP. You might love that. You might hate it.

Why HTTP? Because I didn’t want Cadenya to be an SDK you embed in your application code that is the harness itself. It feels invasive, and you could build one yourself.

I wanted something decoupled. I want an app to receive transactional requests, and real-time webhooks when objectives are active.

Instead, Cadenya’s design is that tools are HTTP/MCP. When your agent in Cadenya calls a tool, we will make a request to the known endpoint for that tool. Simple. But powerful.

In practice, this means you’re more focused on building and deploying API endpoints, with no Cadenya SDKs embedded in your application to orchestrate those endpoints as tool calls.

You can ship an API, I’m assuming.

Why

Building AI functionality should be fast paced, fun, and rewarding. AI is a new tool in our collective belts to (finally) break free from the monotonous software we’ve been building for the last 10 years. No one needs another project management tool with a different coat of paint.

Next-gen AI applications will give humans back immeasurable hours. All of them will need a runtime.

Cadenya is my take on what the runtime should look like.

And it’s built for builders. It’s a “yes-code” platform.