top of page

Agentic Time Traveller

Writer: Darrin Southern
Darrin Southern
3 days ago
5 min read

Updated: 2 days ago

A robot lounges on an ornate throne beside a laptop and a beer while blurred robots rush past in a library
time travel - not as we know it . . .

The Greeks had two words for time. Chronos is the clock: sequential, measured, billed by the hour. Kairos is the right moment: the decision that changes what happens next.


Agentic Time collapses the first and leaves us with the second.


At the start of October I performed an eight-pass review of a Claude Skill, shipped a release, updated three blog posts and corrected a conference deck.


One day. The typing was never the constraint. Every pass stalled at the same place: a decision only I could make.


In this post:



Agentic Time Vocabulary


Agentic Time. Project time when an Agent does the building. Build effort collapses, and the schedule is set by decisions, reviews and approvals instead.


Agentic Time Traveller. The Orchestrator who moves between Agents, projects and contexts, spending the time on decisions, not typing.


Decision Latency. The wait between an Agent finishing and a human deciding. In Agentic Time, it's the critical path.


Agentic Assisted Development. Building software with an Agent doing the production work, and the Developer owning the direction, the review and the record.


Value-Based Billing. Pricing the outcome the client receives, not the hours it took to build.



What Agentic Time Changes on a Project


Traditional plans are cut from build effort. Estimate the scripts, estimate the layouts, add testing, add a buffer. That arithmetic breaks when a first working version arrives before the meeting that was meant to define it.


Three things move.


The critical path moves. It now runs through stakeholder answers, approvals and reviews, not through the build. An Agent can finish in an hour, then wait days for a yes.


Scope gets cheaper to add, not cheaper to carry. Everything is 'quick' to build, so everything gets built. Each extra feature still needs testing, training and support, and that cost stays on the human clock.


Feedback loops shorten. A prototype in the morning, a user's reaction by the afternoon. Requirements stop being a document and become a conversation with a working draft on the table.


Example: The longest waits were all decisions: whether to rename the Skills now or wait for the packaging decision, and whether to push before the review was finished. The Agent did its part in minutes, then waited for me. I held the push, made the calls, and released after review.



How Agentic Time Changes Project Documentation


Documentation has always been the first line cut. Not because anyone disagreed with it. Writing it took time the project didn't have, and the build was always the louder priority.


That trade has flipped. An Agent drafts documentation as a by-product of the work, at every stage:


Discovery. Meeting notes become the Need and the Success Criteria while the conversation is fresh.


Design. Schema decisions, and the reasons behind them.


Build. Script headers, changelogs, version numbers.


Test and Deploy. Test evidence, deployment notes, rollback steps.


Handover. User guides and training notes, written for Developer Next, including you in six months time.


The cost is no longer writing it. It's reviewing it. Documentation an Agent drafted and nobody read is a liability with good formatting. I made the case for this in Develop and Document like a Rockstar back in 2021. The case hasn't changed. The excuse has gone.



How to Run a Project in Agentic Time


The old mindset manages effort. The new one manages decisions. List every point that needs a human yes and sequence those first. The Agent fills the gaps around them.


Treat everything the Agent produces as a draft. A branch, a staging copy, an unpublished post: somewhere reversible, with a human doing the release. It's the same rule as keeping development off the Production Server. Faster building makes that rule more important, not less.


Review the code again when the Harness changes. Same prompt, different Harness, different code. On a FileMaker coding project, that means Claude Desktop, the Model, the Skills, the harness itself and, most of all, the version of the Claris Agentic Development Toolkit (ADT). It's now the main tool for the Agentic FileMaker Developer, and an update can change what the Agent produces. Treat each change like a new contractor joining the team: review the first piece of work before you trust the second.


And protect your review time. Reading is now the long part of the day. Schedule it the way you once scheduled the build.



Orchestrating Multiple Agents as an Agentic Time Traveller


One Agent is a faster pair of hands. Several Agents at once is a different job.


Run an Agent per task, per window, even per computer: one reviewing a schema, one drafting documentation, one running the tests. They all work at the same time. You don't.


That makes the Orchestrator the Agentic Time Traveller: the person who moves between those timelines, hands each Agent the context it needs, and decides what happens next.


Context is the currency. Every Agent starts cold. It knows only what's in its own window, so each brief has to carry the Need, the constraints and the definition of done. That's Context Engineer work, and it's why Skills and written records pay for themselves: stored context you never retype.


Focus has to move. Several projects, several windows, several Agents, and one Developer deciding what gets attention next. The skill is switching context cleanly: note where each thread stands, move to the next, and arrive already briefed.


It's management, not typing. If you've managed a team of human Developers, you've already done this. Delegate, hold the picture, check the work, redirect. The difference is speed. The team finishes before you've switched back, so Decision Latency lands on you.


Example: Helper Agents ran the same ten test cases on Haiku, Sonnet and Opus, and I read the results as one table. Three Agents, one brief, one Developer deciding what to fix.



Where Agentic Developers Focus Next


If the build isn't the long part, the focus moves to the parts around it.


Upstream. Stakeholders, the Need, the Success Criteria. The Agent builds exactly what you describe, quickly, which makes a vague brief more expensive, not cheaper. It's the same list from my FileMaker Agentic Development post, and it matters more now.


Judgement. Prompt once, read twice. Whether an install is production-ready, whether a fix is a fix. It's the skill I wrote about in FileMaker Knowledge Delegation, and it's the one that doesn't expire.


Communication. The Agent doesn't sit in the stakeholder meeting. You do.



Hourly Billing vs Value-Based Billing for Agentic Developers


Hourly billing sells the clock. Agentic Time just shortened it.


If an Agent compresses a week of building into a day, an hourly Developer earns less for a better result. The incentive points the wrong way: the faster and more effective you get, the less you bill.


It was never the typing the client was buying. It was a working solution they can trust, and someone accountable for it. The Agent types. You decide, review and sign off. That's the part with the value, and it doesn't shrink with the clock.


Value-Based Billing prices that outcome: the problem solved, the risk removed, the judgement applied, the record left behind. It needs the Success Criteria agreed up front, which is the upstream work you should have been doing anyway.


There's no one single 'right' way to do this. A hybrid works: discovery by the hour, delivery against a fixed outcome.



Takeaway


Chronos got cheap. Kairos didn't.


The Agentic Time Traveller doesn't just move faster. The job is knowing which moments matter, and being ready when they arrive. Build faster, by all means. Document as you go. Price the kairos, not the chronos.


More to come . . .

Comments


©2026 by CadenceUX | FileMaker is a trademark of Claris, Inc.

bottom of page