Think Log

Imagine an email arrives from a customer.

The AI knows how to deal with it, except for one thing.

So it asks someone.

They answer.

The AI continues the work and replies to the customer.

Nothing particularly revolutionary there.

But something important should have happened.

The organisation should now know something it didn’t know before.

The next time the same question appears, perhaps nobody needs to be interrupted.

Most business systems are very good at recording what happened.

AI systems have the opportunity to do something much more interesting.

They can reduce the organisation’s uncertainty because it happened.

An organisation should get smarter every time it has to ask someone.

I’ve been thinking about authorship in the age of AI.

A lot of my writing now starts as a conversation.

I tell stories. Make arguments. Remember experiences. Challenge things. Change my mind. Come up with metaphors. Reject ideas. Refine others.

AI helps turn that conversation into prose.

So who wrote the article?

An AI detector might confidently tell you AI did.

And technically, it may have generated a lot of the sentences.

But the experiences are mine.

The opinions are mine.

The stories are mine.

The judgement about what stays and what goes is mine.

Perhaps authorship is becoming less about the provenance of the keystrokes and more about the provenance of the thought.

AI wrote this.

I wrote this.

Both things can be true.

The genie is out of the bottle.

AI is here. It can write code, operate tools, communicate with people, make decisions and increasingly perform useful work.

Trying to put the genie back in the bottle probably isn’t the interesting engineering problem anymore.

The interesting problem is:

How do we engineer the frameworks and controls that make this thing useful?

Permissions. Boundaries. Responsibilities. Escalation. Authorization. Audit. Knowing when to act. Knowing when to ask.

Perhaps we should spend less time trying to make AI less capable.

And more time engineering the environment in which that capability can operate safely.

I booked an airport lounge today.

To register for the service, I entered my credit card, address and email.

Then I selected a lounge and went to pay the booking fee.

Enter your credit card.

Enter your address.

Enter your email.

Every individual process worked perfectly.

Registration worked.

Booking worked.

Payment worked.

And collectively they produced completely stupid behaviour.

That’s increasingly what I mean when I talk about Behaviour Engineering.

Don’t just engineer the processes.

Engineer the behaviour for the outcome.

There’s a lot of talk about “vibe coding” at the moment.

But I don’t think that’s what I’m doing.

I’m not asking AI to build something I couldn’t build myself. I’m making architectural decisions, defining behaviour, testing outcomes, spotting when something feels wrong and correcting the direction.

I’m just not writing most of the code anymore.

The workflow has become something more like:

Specify → orchestrate → observe → test → correct → repeat.

And perhaps that’s the important change.

The code hasn’t disappeared. I can descend into it whenever I need to. But increasingly, I’m choosing the altitude at which my experience is most valuable.

Maybe software development isn’t disappearing.

Maybe developers are just moving up an abstraction layer.

Most AI systems still behave like we’re trying to create one omniscient employee: give it more context, more tools, more memory, bigger context windows.

Perhaps that’s the wrong model.

If AI is going to run an organisation, it needs to work like an organisation.

Different responsibilities. Different permissions. Different knowledge. Delegation. Escalation. Asking other people. Asking other AIs. Waiting for answers. Picking work back up afterwards. Knowing who it’s allowed to ask and what it’s allowed to tell them.

It’s been a busy few days. Burned through our co-pilot credits in days, racked up a few hundred more dollars worth of credits too.

+Added

Oauth templates, reflection bindings, reflection script helper for surfaces, surface editor, delegate task tool, assignable agents.

?Exploring

DropPort for ad-hoc transfers between two browsers. Just solves a really annoying problem I had for sometime of transferring files to a VM.

!Observed

AWS SFTP server trying to send an entire directory in a single packet.

It’s important that a platform for building behaviours is NOT exclusively AI centric. This is what Reflections do, they provide a user configurable way to access data from Surfaces like REST endpoints, pages without having to be passed through the LLM.

+Added

Reflection bindings allowing for multiple data sources to be connected up to a single group of Reflections.

+Added

Secrets manager added to Vork for pre-defining or updating existing credentials.

Introduced Reflections, allowing direct access to external data without routing it through AI. Reflections can still be made available to AI when required, and will eventually provide the data layer for Surfaces.

+Added

Gifted Vork its organisational memory.

Until now, Vork had session memory. It could remember facts during a conversation, but everything it knew disappeared with the session.

Today that changed.

Skills can now build and consult persistent organisational knowledge.

Instead of repeatedly explaining how an organisation works, the organisation itself becomes teachable.

For example:

> Define in “purchase order rules” that every order must contain a valid contact email address.

From that point on, every Skill can retrieve and apply that knowledge.

Feels like a small feature.

Probably isn’t.

!Personal

Today is my wife’s 50th birthday

Happy Birthday, my Cancerian Queen ❤️