Last week Felix Rieseberg, who leads engineering for Claude.ai, Cowork and Claude Code Desktop at Anthropic, published How to be more ambitious: A tutorial for humans with models. Read it first. It's short, and it's the best answer I've seen to a question I get asked a lot: I've connected an agent to CodeKasten. Now what?

Felix starts with a line from Terence Tao: models are "astounding in some directions, while inadequate in others". Because they get better unevenly, most of us keep using them for whatever first worked, and that tends to be the small stuff. He then sorts ambition into four kinds:

• Speed: the same work, faster.
• Altitude: aim at the outcome, not the task.
• Depth: work the way the best people in a field work, with their tools and their data.
• Range: bring in what several fields know.

This post goes through the last three for CodeKasten, where an agent can build apps, workflows and reports through the MCP server. Speed you've already got. If all your agent does in CodeKasten is fill in records, that's speed, and it's the least of what it can do.

Altitude: ask what should happen next

Felix's question for altitude is "what do you want to happen next?". His example is moving from "fix this crash" to "keep the apps crash-free". The task is still the same. It's just aimed one goal further out.

In CodeKasten the low-altitude request looks like this:

Add a Priority field to Ticket.

Go one goal higher:

Our support runs out of a shared mailbox and things get lost. Build a Helpdesk app with customers, tickets and statuses. Then build a workflow that tells whoever is on call, in their Inbox, when an urgent ticket comes in, and another that sends the team a summary of open tickets every Monday morning. Work on your own branch, commit, and ask me to merge.

Every part of that maps to a tool the agent already has. In an app workspace it builds the types with create_entity_type, add_field and add_relation. They're the same rows the Entity Builder writes, so you can open them there afterwards. In a workflow workspace it uses list_workflow_functions to see which steps exist, and save_workflow to save an Entity Trigger into Send to Inbox, and a Schedule Trigger into Run Report into Send to Inbox. Then it installs the packages where they'll run and turns them on with create_workflow_instance. You end up with a desk that keeps working, which is more than the field you'd have asked for.

Felix also says something easy to skim past: a workflow that lasts usually means changing your own setup. To keep his apps crash-free, Claude needed the crash reports, a map from versions to commits, and machines on all three operating systems. In CodeKasten that setup is:

• A key on a branch for each workspace the agent works in. An agent acts as the person who made its key, with that person's role, and it never writes to a protected branch. You can hand it a big goal because the worst case is a branch you don't merge.
• The project memory. With the CodeKasten app installed, every session starts with a briefing: the project's profile, its open gaps, the facts the team has settled on, and what you've told the agent about how you work. An agent that remembers can take on goals that run longer than one conversation.
• The Inbox. request_merge and send_to_inbox are how a long-running goal checks in with a person without waiting on one.

This blog is an example of altitude. The Blog app (Post, Category, the address and the cover) was built by an agent through those builder tools, released, and installed like any other package. The post you're reading was written into a Post record on a session branch and is waiting for a person to merge it.

Felix's limits apply here too. Altitude works for outcomes you can describe. "Make our operations better" isn't one. "Nobody should find out about an urgent ticket from the customer" is.

Depth: use the instruments, and let something else judge

Felix's depth advice is to push the model to work the way a leading professional would. That means real instruments instead of markdown tables, goals that seem unreasonable, assumptions checked against raw data, and, most importantly, an outside judge. Don't let the model grade its own work. Give it tools it can run that tell it straight away whether it got things right.

CodeKasten gives an agent real instruments:

• Ask the data, don't guess from it. query_records counts and adds up records over a whole type, or grouped by a field. It's the same question a report asks, compiled in one place and run read-only against the database. An agent asked "which customers are we losing?" should come back with the query and its numbers, not with impressions from twenty records it happened to read.
• Validators, not opinions. save_workflow checks a workflow by the same rules as Validate in the editor: exactly one trigger, every port connected, at least one end, every required setting filled in. It reports all the problems at once and won't compile a workflow that breaks them. The agent hears from the engine, not from itself.
• Branches, commits and merges are the outside judge with the most authority. Every change an agent makes is a reviewable diff on a branch, and a person decides whether it reaches main. Releases are immutable snapshots, so what you approved is exactly what gets installed.

Felix's meta-prompt, which asks the model what a top professional would do, what the rawest material is, which methods and tools they'd use, and what outside evidence would prove the result, works well with CodeKasten as the place where that evidence lives:

TIP

Before you start: what would the best operations lead in our industry build here? What's the rawest data we have (which record types, which fields)? Which reports and workflows would they set up, and which numbers would show it's working? Write that down, then rewrite my request to match, and build it on your branch.

Then set an unreasonable goal. Not "reply to tickets faster", but "no urgent ticket waits more than ten minutes for a person, and we can show it every week." The second one tells the agent what to build: a trigger, an Inbox item to the right person, and a weekly report that would expose a failure.

Range: turn the nouns into verbs

For range Felix borrows a trick from The Art of Innovation: replace the nouns with verbs. A quarterly business review becomes "getting busy people to believe a story about cause and effect." Once the noun is gone you can see the other fields that know how to do the verb.

Try it on what you'd build in CodeKasten:

• A helpdesk becomes "getting each problem to the person who can fix it, and knowing it was fixed." That's routing (a workflow), accountability (a person field and the Inbox) and evidence (a report on a dashboard).
• A CRM becomes "remembering every promise we made to a customer." That's mostly relations and a schedule.
• A content calendar becomes "getting the right thing published at the right time, with someone having checked it." That's a draft and published status, a branch, and a merge. In other words, it's this blog.

Felix's second tool for range is to put together a crew of specialists, and to have the model do what each specialist does rather than play them. With CodeKasten one session can cover a lot of that crew, because the work is all rows in one place:

• the data modeler builds the types in the app workspace,
• the automation engineer builds the workflows in the workflow workspace,
• the analyst asks questions with query_records and saves the good ones as reports,
• the reviewer reads the branch's commits before anything is merged,
• the librarian keeps the facts, the gaps and the skills current for the next session.

His practical requirement is the one that matters most: range needs a computer the model can work on and access to the data. That's what the MCP server is for.

Where range runs out today: connectors

The most valuable verbs reach outside CodeKasten: "tell the customer", "post the video", "file the invoice". That's what connectors are for, and in CodeKasten they're the youngest part, so here's where things actually stand:

• Connectors are built in a connector workspace, released and installed like apps. A workspace links its accounts under Integrations, and the credentials are stored encrypted, never sent to a browser and never shipped in a package.
• In a workflow, Connector Action calls an action with a linked account, and Connector Trigger starts a run when a webhook arrives at the dispatcher. A delivery that arrives twice starts nothing twice.
• What an agent can't do yet: save_workflow refuses connector steps for now, and there are no MCP tools for connector accounts. Core Connectors ships one connector, YouTube, which hasn't yet been run against the real service.

So today an agent can design the whole workflow around a connector: the trigger, the records, the Inbox items, the report that shows whether it worked. A person then adds the connector step on the canvas. Building connectors through MCP is on our list, and when it ships it'll be announced here.

We've been here before

Felix ends on self-efficacy: believing you can do something is one of the better predictors of doing it, and specific, hard goals beat "do your best". He mentions Dantzig solving two open problems he mistook for homework, the four-minute mile being matched within weeks once someone had run it, and Linux being announced as "just a hobby".

I'd add one thing that's specific to tools like ours. Ambition is easier when it's safe to fail. In CodeKasten an agent works on its own branch, can't touch a protected one, commits what it did with a reason, and waits for a person to merge. A release can't change after it's published. So the cost of asking for too much is a branch you close, which makes it reasonable to ask for a lot.

Next time you open a session, don't ask for a field. Ask for the thing you'd want running a month from now, and let the agent tell you what it needs to get there.

Thanks to Felix Rieseberg for the original post. The framework (speed, altitude, depth, range) and the quotes above are his; how they apply to CodeKasten is ours.