Intelligence That Acts
CONFegitech explores and engineers autonomous AI systems that plan complex tasks, use tools, coordinate actions, and verify results within defined boundaries.
Autonomous AI systems engineeringReference model: proposed
01 / Philosophy
Generating an answer ends when the text appears. Completing a multi-step task means understanding what is wanted, planning the work, choosing tools it is allowed to use, carrying out the steps, and checking the result against what “done” means.
A · A conversational system
B · An action-oriented system
A goal is stated together with its constraints, and "done" is defined as criteria that can be checked.
The goal is ambiguous or the criteria cannot be checked, so the system proceeds on a guess.
Clarifying questions, required acceptance criteria, explicit scope limits.
Verification can send work back to planning. It is a loop, not a line.
02 / Challenges
These are the problems CONFegitech’s work is organized around. They are open engineering questions, not solved ones.
P-01
Turning a loosely worded goal into steps that are specific, ordered and checkable.
Natural-language goals hide assumptions. A plan that reads well can omit a dependency, and the omission may only surface several steps later. A plan also has to stay revisable: the first surprising result should change it, not break it.
→ Objective Interpretation · Planning Engine
P-02
Matching each step to a capability the system may use, with the right parameters.
Tools overlap and their descriptions are imperfect. An error can look like a success, and choosing gets harder as the toolset grows.
→ Tool Execution Layer
P-03
Keeping what matters across many steps without exceeding limits, and without keeping what should be forgotten.
Context is finite, summarising loses detail, and retaining sensitive data creates obligations. Stale context produces confident mistakes.
→ Context and Memory
P-04
Detecting that a step failed, working out why, and choosing between retry, alternative, replan or stop.
Failures are often partial. Retrying a non-idempotent action can repeat its effect, and some failures should end the run entirely.
→ Tool Execution Layer · Planning Engine
P-05
Deciding whether a result actually satisfies the objective.
Fluent output can be wrong. Deterministic checks exist for some tasks and not others, and a system grading its own work shares its own blind spots.
→ Verification Engine
P-06
Keeping a run inside its permissions, its budgets for cost and time, and the points where a person must decide.
Agents combine tools in ways designers did not list in advance. Loops and retries compound cost, and knowing when to ask a human depends on consequences, not just model confidence.
→ Safety and Control Layer
03 / Reference architecture
Six components, one control layer drawn apart from the rest, and a feedback loop from verification back to planning.
Fig. 2Conceptual reference architecture: proposed design, not a representation of a verified production deployment.
04 / Focus areas
Each is a technical focus, not a finished product. Each comes with the question we consider hardest.
Breaking complex objectives into structured execution steps.
A plan is treated as an artefact: stored in a structured form, with dependencies and a checkable criterion on every step, so that anyone can review it and the system can revise it deliberately.
Hardest questionHow do you know a plan is adequate before you run it?
See how this fits the modelConnecting agents to approved APIs, software and execution environments.
Every tool is described by a contract: what it takes, what it returns, what it can change and what it costs. Access is granted per task and classified by side effect.
Hardest questionHow should tools be described so selection stays reliable as the toolset grows?
See how this fits the modelHandling unexpected results and recoverable failures.
Errors are classified rather than treated alike. A transient fault may justify a bounded retry, a wrong approach may justify an alternative route, and an unsafe state should end the run with a clear report.
Hardest questionWhen is retrying right, and when is stopping right?
See how this fits the modelMaintaining relevant task context under defined privacy and retention rules.
Working context, task state and anything retained longer are kept apart, each with a scope, a reason to exist and a rule for when it expires.
Hardest questionWhat should an agent forget?
See how this fits the modelChecking results against explicit completion criteria.
A result is reported complete only after it is checked against criteria set at the start, using the strongest check available, and the evidence is stored with the run.
Hardest questionWho checks the checker?
See how this fits the modelAdvise
The system proposes. A person performs every action.
Assist
The system acts only after a person approves each action.
Supervised
The system acts within defined limits. A person approves consequential actions and reviews results.
Delegated
The system acts within policy and budget and escalates exceptions. Limited to tasks with strong verification and monitoring.
Levels describe a design space, not a product tier. No level removes human accountability.
Enforcing permissions, execution limits and approval requirements.
Autonomy is graded, not binary. How much a system may do alone depends on the task, its permissions, the strength of verification and the cost of a wrong action.
Hardest questionHow much autonomy does the evidence justify, and for which tasks?
See how this fits the model05 / Applications
Conceptual scenarios, not products and not case studies. Each one describes a realistic problem and how an appropriately designed agent could take part, with a person kept in charge of consequential steps.
Agents that inspect a codebase, analyze an issue, propose changes, and run permitted tests.
A team must upgrade a library across a service whose test coverage is uneven.
Agents that gather information, compare sources, and produce structured summaries.
An analyst needs a sourced comparison of several approaches to a technical problem.
Agents that examine datasets, execute approved analyses, and report findings.
A team wants to know why a metric changed between two periods.
Agents that assist with diagnosis, predefined operational procedures, and controlled execution.
An alert fires, and the on-call engineer wants a first diagnostic pass before joining.
Agents that coordinate repetitive, rules-based tasks across authorized systems.
A routine request, such as onboarding a vendor, spans several systems.
Agents that connect development workflows with approved APIs and utilities.
A platform team wants an assistant that knows its conventions and can run its checks.
06 / Demonstrations
No live demonstrations are published yet. These are the four we intend to build, how each would work, and the labels we will use so nothing is shown as more than it is.
Answer a technical question from an approved set of documents and produce a structured report.
Analyze a small coding task in a sample repository, propose a change and report the test outcome.
Examine a public or clearly labelled synthetic dataset and answer a question with evidence.
Coordinate specialist agents to complete a larger objective, then compare against a single agent doing the same job.
Concept preview · How a recorded run could be presented
Interface concept. It contains no data, no outputs and no controls, and does not represent a working system.
07 / Reliability
Any agent that can take consequential actions needs explicit permissions, review points, logs and checks. These seven controls are design requirements we work to, not certifications or guarantees.
An agent that can act can act wrongly. Tools are allow-listed, scoped to the task and classified by side effect, so anything unlisted is simply unavailable.
Irreversible or externally visible actions pause for a person, who receives the evidence needed to decide rather than a bare yes-or-no prompt.
Loops and retries compound. Budgets for calls, cost and wall-clock time keep a run bounded and give it a defined place to stop.
A report of success is a claim. Results are checked against criteria set before the work began, and the evidence is kept.
Failures are classified, retries are bounded, and unsafe states end the run with a report a person can act on.
Plans, tool calls, policy decisions, checks and approvals are recorded so a run can be debugged, audited and used to improve the system.
Task data has a defined scope, retention and deletion rule. Sensitive fields are minimised or redacted, including in the traces themselves.
Illustrative log format. Not output from a real system. Hover or focus a control to see which lines it relates to.
What we do not claim
We do not claim zero errors, complete security, or unsupervised operation in every environment. Controls reduce and expose risk; they do not remove it.
Safety and control in detail08 / Perspective
Six engineering principles shape how we approach dependable agentic systems. Each one is a position you can disagree with.
An objective carries its constraints and acceptance criteria before work starts, so completion can be checked rather than asserted.
A plan is a stored, reviewable artefact with dependencies, not something implied by a chain of calls. Every step is a state with defined transitions.
Access is granted per task, narrowly, and expires. Tools are contracts with declared scope, side effects and cost.
If you cannot see what an agent planned, called, received and decided, you cannot debug, audit or improve it.
Use the strongest check available: deterministic first, then reference comparisons, then model-assisted judgement with its limits in mind.
People stay in charge of consequence. Oversight has to be designed so it is possible to do well, not merely present.
No papers or results are published yet. The research page lists the open questions we want to work on.
Research directionsContact
Have a complex technical challenge or an idea involving autonomous AI systems? Let’s explore what can be engineered.