The software factory ends at the customer
As intelligence becomes abundant, software becomes a temporary, trustworthy expression of one person's intent.
Traditional software begins with repetition. A company notices that many people want roughly the same thing, turns that common demand into an application, and asks every customer to adapt to its interface and rules.
Agents invert that sequence. The starting point is no longer an application. It is a specific human intention, expressed at the moment it matters.
A product for one moment
Imagine asking an agent to take fifty dollars, present it as a beautiful digital cheque, and send it to a friend. Only the owner of one email address may cash it. Forwarding the message must not transfer the right to claim it. If it remains unclaimed, the money returns automatically.
A traditional company would first decide whether enough people want this feature, design a product around it, build accounts and screens, and distribute the application. An agent can instead compose a payment provider, identity verification, email delivery, a single-use claim token, and a temporary interface into one purpose-built workflow.
The workflow exists because the intention exists. Once the outcome is reached, the product can disappear.
Compose the logic. Reuse the trust.
The valuable components are not generated from scratch. Payments come from a proven payment rail. Email comes from a proven delivery service. Identity, storage, signing, and observability come from systems with known contracts.
What changes is the business logic between them: who may claim the money, when the claim expires, what happens after failure, and what evidence counts as completion. Agents make this layer dynamic.
The opportunity is not merely tool calling. Tool calling will become a commodity. The hard problem is allowing logic to change without allowing trust to become improvised.
How can a temporary workflow be trusted?
Reliability cannot be established by the agent saying its plan looks correct. It must be demonstrated through evidence at every boundary.
- Declare the contract. Convert the request into explicit inputs, permissions, invariants, success conditions, and failure behavior.
- Use verified capabilities. Every component exposes typed operations, bounded permissions, known failure modes, and test evidence.
- Check invariants. Money cannot be created twice. A claim cannot be redeemed twice. Authorization cannot change because an email was forwarded.
- Make execution recoverable. Every step is idempotent, retryable, or paired with a compensation.
- Test the composed plan. Simulate timeouts, duplicates, partial failures, unauthorized claims, and expiration before releasing real money.
- Record the proof. Produce a signed trace of what was authorized, executed, verified, and compensated.
- Verify the outcome. Completion means the user's condition is true—not merely that every API returned 200.
A mature application earns trust through repetition: the same fixed flow is tested millions of times. A composed workflow must earn equivalent confidence differently—through constrained components, machine-checkable invariants, adversarial simulation, and runtime evidence.
Where Ofabu begins
The long-term idea is an intent execution layer: a system that composes proven capabilities into temporary software and remains accountable for the result.
But a general platform is not the starting point. The starting point is one narrow domain with many underserved, variable requests. Deliver those requests with existing infrastructure. Observe which safety mechanisms recur. Turn only those repeated mechanisms into the runtime.
The platform should emerge from completed transactions, not from an abstract architecture.
Intent in. Outcome out.