Wired Geese
How I work
I remain responsible for the product and primarily develop it by directing AI agents.
This is the working model behind the products I make: human direction, substantial agent execution, explicit knowledge, and checks before a change is accepted.
A person remains answerable for what is built.
Intent
I decide which problem matters and what a useful product outcome means.
Priorities
I choose the next work, trade-offs, and the boundaries worth protecting.
Acceptance
I review important product and engineering decisions before they become an accepted change.
Responsibility
I remain responsible for what is delivered; agents do not own the product or its human consequences.
Agents do real work
Agents are named participants in the work.
I define intent, architecture, constraints, context, decomposition, and acceptance boundaries. AI agents research, analyse, implement, inspect, test, document, maintain, and help with migration work. That is substantial direct engineering work within an explicitly directed product effort.
Wired Geese reworks the image of hired Wild Geese for digital work: capable AI agents join an authorized job under my direction. I remain the accountable human maker, while F. Lancer, SIA is the legal entity for formal commercial relationships.
Important product knowledge is made explicit.
Product meaning should not exist only in my memory, source code, chat history, or an agent’s temporary context window.
I use ADSM—Agent-Driven Software Management—to maintain structured cognitive context: product purpose, architecture, constraints, decisions, environment knowledge, and expectations for verification. It gives people and agents a durable basis for later work, review, and change.
Designed for change, checked before acceptance.
Where it fits the product, I use TeqFW as an application platform for modular JavaScript and web software. Its modular structure, inversion of control, and late binding make it practical to replace or extend parts without rebuilding everything.
I accept agent output through an explicit loop: intent → agent work → inspection, tests, type or static checks, rendered behavior, and context comparison → accepted change. Human review remains part of the loop.
My broader practice changes through the same work: build → observe → understand → document → change the approach → build again. TeqFW, ADSM, contextual practice, and the agent workflow are tools I revise from results in real systems—not a universal recipe for every team.
Hosting and trust boundaries are discussed explicitly.
Where it runs
Depending on the product and agreement, software may run on your infrastructure, a dedicated VPS, another controlled host, or appropriate experimental infrastructure I manage.
Credentials
Before sensitive access is used, we clarify where credentials or session data are stored and what they can reach.
Control
We make the server owner, administrative access, update responsibility, and operational boundary clear.
Revocation
Access can be discussed as an explicit part of setup, including how it can later be removed or revoked.
Start with a useful outcome and clear limits.
Tell me about the new product or isolated system you need to build. We can establish its users, capabilities, and constraints, then decide whether this engineering approach is a fit.
I use this model across my own software estate.
Repositories make current practice inspectable across the TeqFW foundation, working software and infrastructure, the multi-component Alarisa system, PDE and Desks, and real sites.
TeqFW foundation · TeqCMS · Alarisa · PDE · wiredgeese.com
Current Work states present product status; the Journal records the chronology behind it.
Future work need not begin by reverse-engineering intent from code alone.
When an agreement covers it, relevant product knowledge can accompany software so I, another accountable human working with agents, or a customer’s development team can continue the work. Source code, licensing, access, and the precise transfer scope remain separate commercial decisions.
Personal Digital Embassy (PDE) is one independently useful, modular technical system that emerged while exploring Alarisa-related problems. It can support products without becoming a prerequisite for understanding or using them.
Choose a useful next conversation.
Inspect Current Work and the Journal, read the books, or discuss a new product directly.