Agent Autonomy - Part 2: Going Beyond Algorithms

Introduction

In Part 1, Agent Autonomy — How to Solve Algorithmic Problems, I used circle packing to explore how a coding agent can organize a search. Classical algorithms, numerical optimization, evolutionary search, and learned proposals can play complementary roles. The practical question was how much of the orchestration I needed to write myself.

The setup had three useful ingredients:

• A bounded objective: a specified score and constraints.
• A protected evaluator: the agent cannot edit the scoring rules; the evaluator still needs to check the actual problem.
• A flexible coding environment: the agent can propose, run, and revise code without a bespoke controller for every step.

The useful result from Part 1 was a change in who organized the search. I did not hand-code the orchestration framework, but the agent still wrote and ran code. Its reported packing score was promising; it was not an independently verified world record. Now I want to examine a harder evaluation problem.

Beyond Algorithms: What Does a Vibe Coder Actually Need to Solve?

Solving complex bounded problems and beating the complexity beast is very promising. But let's be honest—in real-world applications, you rarely face problems with clean immutable harnesses.

Let’s try a question closer to product work: how do we build an interactive explanation of Merge Sort and Count-Min Sketch? The scope is bounded, but quality depends on a person learning from it. I want the clarity of a Distill article or a Jay Alammar diagram, not just a page of moving buttons.

To establish a baseline, here are demos built by a coding agent without agent autonomy:

As you can see, the demos are functional but not particularly engaging. They miss the visual concepts that make them truly educational and show a limited understanding of what humans find compelling.

What Does It Mean to Vibe Code Something?

Let's look under the covers. When you vibe code a bounded creative problem, you're actually operating on five distinct layers:

Layer 0: The LLM
How do you make a smart machine? This is the foundation—the raw intelligence that powers everything. Billions of parameters, trained on the written record of humanity. Transformers, attention, pre and post training. This layer of abstraction that is largely provided by frontier labs (OpenAI, Anthropic, Google, Meta). Most likely, you don't build this—you use it.

Layer 1: The Coding Agent
How do you turn an LLM into an effective coding partner? Raw LLMs can write code, but coding agents add crucial infrastructure: efficient diff tools for precise edits, planning and search for complex tasks, execution APIs to run and test code, context management (compression, retrieval, prioritization) when your session is too long for an LLM, also code repo understanding or mapping. This is Claude Code, Antigravity, Cursor, Aider, Devin—the tools that make LLMs practical for software development.

Layer 2: Software Infrastructure
The agent can write code, but you still need working authentication, a database, hosting, and separate test and production environments. Platforms can package some of those decisions. That is the infrastructure layer: it makes an application easier to run, while leaving the question of what makes it useful.

Layer 3: The Core Problem-Solving
How do you solve the creative problem itself? Tools can plan and generate candidates, but someone still has to notice that a working demo teaches the wrong idea. For the bounded tasks in this post, the challenge is organizing that judgment and the search it directs.

Layer 4: Intention & Goals
What are you actually trying to achieve? This is how we evolve our goals and opinions as we build. Software development is often agile, driven by OKRs that refine over time. Same here: you start simple ("visualize merge sort"), see what you built, and refine what you actually need ("help learners build intuition for divide-and-conquer thinking"). The goal emerges from the work.

Here's how this plays out in practice: say you want to build a demo for Merge Sort. Should you train an LLM to build demos (Layer 0)? Build infrastructure for educational demos (Layer 2)? Or just vibe code it (Layer 3)? Working on the right layer of abstraction saves you tons of overhead and lets you focus on what actually matters. For most vibe coders, the answer is Layer 3—the problem-solving layer. That's where the leverage is.

Layer 3 is the focus here: the loop that turns a vague goal into candidates, evidence, and revisions. How much of that loop can an agent carry between human interventions?

In the Vibe Coder's Seat (Layer 3)

Layer 3 is the fun part: building something whose success is partly a matter of judgment. Correct code is necessary. For our Merge Sort demo, it is not sufficient: the learner should understand why splitting and merging work. We can test the algorithm deterministically while investigating learning with different evidence. Six challenges, plus a research step, help organize the work.

Let's map each to our running example:

1. Handling Computational Complexity

The Problem: Building a demo involves a combinatorial explosion of decisions. Layout: tree view or flat? Colors: by state or by operation? Interactions: step-by-step or continuous animation? Each choice branches into more choices. For a Merge Sort demo alone, you face thousands of possible design combinations—and that's before considering pedagogical framing.

The design space is too large to enumerate casually. That does not make “build a good demo” a formally defined NP-hard problem. It means we need a search strategy: choose promising directions, test them, and decide which uncertainty is worth another attempt.

What We Know: In Part 1, we moved from algorithms to the algorithm vortex. We flipped the script: instead of you designing an algorithm that searches the solution space, let a coding agent search the algorithm space itself. This is neuro-symbolic: a neural coding agent producing symbolic code.

For Demos: Same principle. Don't search for "the best demo." Search for the best approach to building demos. Let the agent invent visualization strategies, pedagogical structures, interaction patterns. The complexity explosion isn't in finding answers—it's in finding the right questions. Let the coding agent explore solutions for you.

2. Decision-Making Under Uncertainty

The Problem: Creative work returns noisy, purpose-dependent feedback. We can write a score, but we do not have a score that perfectly captures educational value. How do we improve the artifact without confusing the score with the goal?

The RL Primer

Unlike supervised ML where you get (input, label) pairs, reinforcement learning is about figuring things out yourself. You take actions, get rewards, and learn what works. The beauty: we don't need to know how a robot should walk—just how to tell it "you're doing great." It explores and figures out walking on its own. Like telling a kid: get chocolate? Great. Grounded till tomorrow? Not great.

The RL loop:

1. Take an action in the environment
2. Observe the reward (positive or negative feedback)
3. Update your policy to maximize future rewards
4. Repeat to improve the policy; optimal behavior is not guaranteed

But RL has two problems:

1. You need a reward function. Someone must define "good" mathematically. For "make this demo engaging"? That's subjective.
2. Random exploration is expensive. A robot takes forever to even stand up by random flailing.

Three related ideas, with different machinery

A world model predicts aspects of an environment so an agent can evaluate possible actions in simulation. That may reduce expensive interaction, but a wrong world model can make an excellent plan for a world that does not exist.

Decision Transformer takes another route: learn from sequences of returns, states, and actions, then condition action generation on a desired return. Its 2021 paper tested offline RL tasks. Asking for a higher return does not guarantee an achievable trajectory, especially beyond the data.

An instruction-following LLM can also generate a plan from a desired outcome: “make the lesson clearer” may produce suggestions to reveal recursion, add controls, or show a counterexample. This is the analogy I find useful. But text pretraining does not automatically supply a calibrated world model or recover the user's true reward function.

The practical loop is to propose, observe, and revise. The model interprets “better”; the evaluation must check whether that interpretation helped. There is no escape from the second half of the loop.

OPRO: Making It Explicit

Google DeepMind's OPRO (Optimization by PROmpting) systematizes this loop:

1. Show the LLM past solutions and their scores
2. Ask: "generate something better"
3. Evaluate, add to history, repeat

Example: In its linear-regression experiments, OPRO proposes coefficients using earlier candidates and their measured errors. The search avoids differentiating the objective, but it still needs an evaluator. The paper demonstrates performance on particular tasks, not a general guarantee of convergence.

Results on prompts:

• Up to 8% improvement on GSM8K (grade-school math)
• Up to 50% improvement on Big-Bench Hard (complex reasoning)
• Discovered prompts like "Take a deep breath and work on this problem step-by-step"

That supports trying LLM-guided search on code, designs, and strategies. Whether it improves them depends on the model, feedback, budget, and task. “Describe the objective in language” is an interface, not a universal optimization theorem.

Here's an example from the paper—OPRO solving the Traveling Salesman Problem. The meta-prompt shows past traces and their lengths. The LLM generates a new trace with shorter length, purely by reasoning about the pattern:

Vibe Coding as Iterative Search

Vibe coding is OPRO generalized:

1. "Make a merge sort demo" → initial attempt
2. "Needs to be more pedagogical" → refined
3. "Add step-by-step controls" → refined
4. "Colors should track recursion depth" → refined

Each prompt refines the reward description. The LLM infers "better" and explores.

The takeaway: an LLM can propose revisions from goals, examples, and feedback. This resembles goal-conditioned search. It does not mean ordinary prompting is technically the same training procedure as upside-down RL.

3. Theory of Mind

The Problem: Applications we build don't just need to function—they need to understand users. Educational content must model what learners will understand, misunderstand, find engaging, or find confusing. This requires reasoning about other minds—what cognitive scientists call Theory of Mind (ToM).

Here's the challenge: when you design a Merge Sort demo, you need to predict that a learner will get confused about why we divide before we merge. You need to know they'll miss the recursive structure if you only show bars moving. You need to anticipate the question: "but why not just sort directly?"

This is hard. Most engineers design for themselves—people who already understand. Designing for the confused requires modeling a mind that doesn't know what you know.

What the research supports: LLMs have performed well on some tasks designed to test reasoning about beliefs, intentions, and indirect requests. Strachan and colleagues' 2024 study also found important differences across models and tasks. Success on these tests does not establish human-like mental experience or make a model a representative novice.

For demos: I prompted Claude to act as a confused student. It asked why we kept dividing instead of showing the payoff of merging. That was a useful design hypothesis. It became a reason to test a clearer explanation, not evidence that real learners necessarily had that confusion.

A stronger check asks a learner to predict the next merge step, explain why it works, and apply the idea to a new array. Judge their answers against the learning objective. The model's simulated reaction can help design this test; it cannot replace its result.

4. Creative Horizons (The Honest Gap)

The Problem: Creativity isn't just exploring a search space—it's inventing new dimensions to explore.

AlphaGo did not enumerate all Go positions. It combined learned guidance with search inside fixed rules. For a creative task, we may also want to change the representation or the question: a different visualization can open a different part of the design space.

For demos, this means: a skilled human designer might look at Merge Sort and say, "What if we visualized it as a family tree instead of bars? What if we told its story as a narrative, not an algorithm?" These aren't moves in a known space. They're expansions of the space itself.

What remains uncertain: longer task completion and creative reframing are different abilities. METR's March 2025 report measured software-task horizons using human completion time and a 50% model success threshold. Its historical doubling trend is evidence about that benchmark, not a measurement of originality or a promise about future progress.

For this demo, the useful experiment is smaller: does proposing several representations produce a better explanation than repeatedly polishing the first one?

The practical move: better models may help, but we can also improve the search now by giving it useful patterns and constraints.

For Demos: This is where skill-based prompting matters. Skills encode human creative heuristics:

• "Try a tree visualization instead of bars"
• "Use color to track state through time"
• "Show before/after comparisons"
• "Add a 'why does this matter' framing"

Skills don't make the LLM creative. They guide exploration into productive regions that the LLM wouldn't discover on its own. We trade infinite creativity for guided creativity—and for bounded problems, that's often enough.

5. Evaluation: Make the Evidence Match the Claim

A rubric can catch missing controls, incorrect explanations, and unreadable labels. It becomes dangerous when “passes the rubric” quietly turns into “teaches well.” The optimizer learns what earns points; the student has to learn merge sort.

The classic CoastRunners example makes the mismatch vivid: a racing agent found a way to collect points by circling a small area rather than finishing the race. The lesson is about a proxy objective. It does not mean every explicit rubric fails, or that removing the rubric removes the proxy.

1. Start with a use case. “Which demo helps a beginner predict the next merge step?” gives the evaluator a concrete purpose. Keep the audience and learning objective visible to the builder too. Hiding what success means would make the task incoherent.

2. Compare candidates. Pairwise judgments can be easier than assigning a score out of five. Randomize presentation order, hide candidate identity, allow ties, and ask for reasons tied to the use case. A judge can still prefer polish over substance; pairwise evaluation does not eliminate bias.

3. Use Bradley–Terry when its assumptions fit. Sparse comparisons can support a shared ranking if the comparison graph is connected and the preference model is reasonable. A complete set of pairs has quadratic size; the estimator need not collect them all. Report uncertainty and disagreement. Strong preference cycles are a warning against forcing everything onto one quality axis.

4. Use the browser as behavioral evidence. Have the evaluator click the controls, step through the explanation, and try edge cases. This reveals things source review misses: a button that looks active but does nothing, a state that cannot be reached, a label hidden at a narrow width. But an AI struggling with a page is not proof that a student will struggle, and an AI completing it is not proof that a student learned.

5. Calibrate with references and people. Reference explanations help name a desired quality: a visible invariant, a good counterexample, a clear transition from intuition to procedure. Compare those features, rather than demanding that merge sort “match” an unrelated Fourier-transform video. For learning claims, test learners on a new problem after using the demo.

What isolation does—and does not—buy

Separate the roles so that builders receive feedback after submitting, and evaluators record their own judgment before seeing other judgments. Keep held-out tests and private evaluation examples out of the optimization loop. The builder should still know the requirements.

This reduces leakage, anchoring, and direct imitation. It does not make judges statistically independent: copies of the same model may share the same mistakes. Repeated feedback can also teach a builder to exploit a hidden judge. Use fresh checks and human review for the final candidate.

The goal is a chain of evidence: algorithm checks establish correctness; browser use establishes observable behavior; comparative review identifies promising designs; learner tests assess learning. No single score has to pretend it measured all four.

6. Visual Thinking & Storyboarding

The Problem: Educational demos aren't just code—they're visual stories. Building them requires spatial reasoning, composition, and narrative flow. Can AI think visually?

What We Know: You think ChatGPT is scary smart? Wait until you see what image generation models can do. They're not just drawing pretty pictures—they understand algorithms, data structures, and abstract mathematical concepts.

We tested this by prompting Gemini to design UX mockups for algorithm tutorials. No prompt engineering—just "design an interactive tutorial for [algorithm]." Here's what it produced:

These mockups offer design material at several levels:

• Structure: recursion trees, hash tables, search graphs.
• Teaching ideas: color cues, staged explanations, step-by-step controls.
• Layout: hierarchy and possible places for interaction.

Whiteboard-of-Thought (2024) gives a concrete example of switching modalities: a model writes code to draw a visual aid, then examines the image to continue reasoning. The paper reports results on four visual and spatial reasoning tasks. It supports trying visual intermediate steps; it does not establish that a generated teaching mockup teaches well.

For Demos: Some of these images have garbled text and wrong details. But holy shit, they still give me a design direction. A coding agent can turn that direction into something interactive; then we can check the algorithm, inspect the interaction, and see whether a learner understands it. The image is a hypothesis to develop.

7. Research (Bonus: Strategic Leverage)

The Problem: Should agents start from scratch, or build on what others have done? Both have trade-offs.

A useful starting point: An agent building a Merge Sort demo can examine existing explanations from Distill, 3Blue1Brown, or VisuAlgo. A research tool can help gather candidates, but the sources still need to be read and checked. A quick survey is not knowledge of an entire field.

There is a design choice here: how much of an existing solution should the builder see?

Full examples help with conventions and details, but can anchor the agent to one design. Extracted principles leave more room for a different implementation, but can omit essential context. I use each deliberately:

• Examples and source code when accurate reproduction or learning a convention matters.
• Patterns and principles when I want to explore alternative designs.
• Held-out reference solutions when I want to test what the builder can produce without seeing the answer.

Hiding a reference solution helps keep that evaluation meaningful. It does not force creativity or guarantee a breakthrough. Builders still need the requirements and enough background to do the work.

For Demos: Start with teaching principles such as showing intermediate states and reducing unnecessary cognitive load. If the builder keeps misunderstanding an algorithm, provide a worked example. Restricting information is a tool for a particular experiment, not a universal rule for better design.

Our Philosophy

The Landscape Today

The thread across these examples is a division of work: models propose, tools expose behavior, evaluators compare, and humans check whether the evidence answers the intended question. A beautiful screenshot, a favorable judge, and a student who can explain recursion are three different results. The architecture should help us move between them without pretending they are interchangeable.

Some bottlenecks are architectural: weak feedback, repeated work, missing context, or a search that never tries a different representation. Others are capability limits. This design targets the architectural problems; it does not establish that the remaining limits disappear.

Deep Mode: Our Philosophy for Agent Autonomy

So what is Deep Mode? It's the missing architecture for Layer 3. When you press "deep mode," you're not just asking for a smarter response—you're asking the agent to autonomously solve the problem through orchestrated evolution, multi-perspective evaluation, and accumulated wisdom.

Here's our philosophy in four parts:

1. Layered Abstraction: Work at the Right Level

The five-layer model isn't just descriptive—it's prescriptive. You can't solve a problem if you're working at the wrong layer.

• If the model cannot solve the underlying task, improve Layer 0 or 1.
• If the application cannot run reliably, fix Layer 2.
• If it runs but keeps improving the wrong thing, examine Layer 3 and the goal in Layer 4.

Most vibe coding frustration comes from layer confusion. You're tweaking prompts when the problem is evaluation. You're fixing infrastructure when the problem is epistemology. The layers clarify where to intervene.

2. Patterns with Consequences: The Right Epistemology

The pattern library is a way to retain lessons explicitly during use. An experiment produces a candidate pattern, the circumstances in which it helped, and the trade-offs it introduced. That is distinct from updating model weights, and compatible with models trained through ML or RL.

Patterns aren't recipes. Recipes are mechanical: "do step 1, 2, 3." Patterns carry consequences. When you choose a pattern ("use a tree visualization for recursive algorithms"), you're accepting a way of thinking and a set of trade-offs. Trees reveal structure but hide the array operations. Understanding patterns means understanding why they work and what you sacrifice when you use them. And these patterns are very familiar if you know computer science or software engineering: start small and add complexity, try it on a simple case then scale up, if a direction gives you high variance in returns, it's worth exploring more than a dimension with small variance.

Keep two forms of adaptation separate:

• Training: update model parameters using a learning objective.
• This workflow: update the artifact, search history, and human-readable pattern library.

The workflow still uses evaluations. It does not somehow operate without feedback because its lessons are written in language.

Patterns are more collaborative. You can read them, critique them, extend them. They're not black-box weights—they're shared vocabulary. And they extend horizons: a pattern learned from educational demos applies to marketing pages, documentation, onboarding flows.

The aim is to preserve experiments as inspectable lessons: what we tried, what changed, who benefited, and where the pattern failed. A rule copied into a skill should carry those limits with it. Otherwise the pattern library becomes another confident narrator.

3. The Pattern Encyclopedia

Christopher Alexander wrote A Pattern Language for architecture—253 patterns that compose to create livable spaces. Patterns like "every room should have light from two sides." Each pattern has a name, a problem, a solution, and connections to other patterns. Architects don't reinvent from scratch; they draw from the library. Software engineers became obsessed with the book and created the famous design patterns book, Gang of Four. Beautiful! These books don't tell you "follow this recipe"—they tell you "here are beautiful patterns; create your own."

We need the same for agent autonomy.

Imagine a Pattern Encyclopedia for Deep Mode:

• "Multi-Evaluator Independence": Reduce leakage with separate evaluators
• "Strategic Constraint": Hold back reference solutions to encourage independent attempts
• "Visual-Linguistic Bridge": Use image models for intuition, coding models for rigor
• "Pair Comparison Scaling": Rank from sparse pairwise judgments via Bradley-Terry

Each pattern named. Each consequence documented. Each composition rule explicit. The library grows across domains: educational demos, marketing pages, data visualizations, documentation. The patterns transfer.

Horizontal scaling means writing this library across genres: educational demos, marketing pages, data visualizations, internal tools, documentation. The patterns transfer; the library grows.

4. The Architecture Itself

The fourth pillar is the actual system: orchestrator, builders, evaluators, browser, skills. We'll show this in detail below. The key insight: separation of concerns.

• Builders know the requirements; held-out evaluations stay private.
• Evaluators record judgments separately before comparing notes.
• Skills make relevant expertise available during the task.
• Browser interaction supplies evidence about actual behavior.

The Fluent Autonomy (The Future)

Today, we teach these patterns to LLMs through prompting and skill systems. They can execute, but they're not fluent. We provide orchestration; they provide execution. But sometimes orchestrators forget they orchestrate and start writing code. Evaluators forget isolation and leak benchmark features. This works, but it's not fluent.

The future? LLMs trained on this kind of work have fluent autonomy. Models that natively understand Layer 3: evaluation design, isolation boundaries, evolution loops. Fluent in autonomy, not just capable when prompted.

But even fluent models should consult the pattern library. A great scientist knows their field deeply—but still references the literature. The patterns aren't training wheels. They're accumulated wisdom. A fluent agent internalizes the principles and knows when to look things up.

That's the vision: not autonomous agents that work alone, but agents that work with compiled human wisdom—extending it, applying it, and occasionally adding to it.

Putting It Into Practice: The Educational Demo System

Now let's see how these principles translate into a working system. We built an agent architecture specifically for evolving educational demos—applying the philosophy from above.

The Architecture

The Orchestrator never builds demo code itself. Instead, it:

1. Spawns builder agents with specific skills (patterns)
2. Receives their output
3. Spawns evaluator agents to assess them (browser-based)
4. Decides what to do next (crossover, mutate, simplify, iterate)

Builders implement specific strategies:

• "Builder A: Use a tree visualization"
• "Builder B: Use an interactive lesson pathway"
• "Builder C: Crossover—tree in the center, lessons on the side"

Evaluators assess without seeing the code:

• Pedagogical evaluator: Opens demo in Chrome, interacts like a student
• Test case evaluator: Runs learning objective checklist

The Algorithmic Vortex in Action

Instead of simple code evolution (mutate → evaluate → repeat), we let agents explore the algorithmic vortex—a vocabulary of operations:

• crossover — Blend ideas from multiple previous agents
• add_sophistication — Deepen visual complexity
• simplify — Strip to core concept, reduce cognitive load
• fix_bugs — Repair issues found in evaluation
• iterate_patterns — Try entirely new visual metaphors
• improve_pedagogy — Enhance learning effectiveness

The orchestrator assigns direction and operations. Agents discover the implementation.

The Evolved Solutions

The embedded candidates below show the results selected from the evolution runs. Compare their structure with the baseline demos above. The generation labels identify saved artifacts; they are not a controlled measure of how much evolution improved learning.

What you're seeing:

Merge Sort: Baseline (simple bars) → Evolved (tree visualization with phases)

• Baseline: Bars animate. You see sorting happen. But why are we dividing?
• Evolved: A tree reveals the recursive structure. Colors track phases (dividing → merged → sorted). The design aims to expose why the merge step works; whether learners grasp it needs a learner test.

Count-Min Sketch: Baseline (functional grid) → Evolved (lesson pathway + heatmap)

• Baseline: A table appears. Numbers increment. Functionally correct, pedagogically hollow.
• Evolved: Structured lessons emerge. Items are color-coded. Hash collisions visualized with heatmaps. The space-accuracy tradeoff becomes visceral.

These demos emerged through iterative evolution—not from any single prompt, but from orchestration. Each generation built on the previous. No human wrote these details. The agents discovered them.

Conclusion

The demos show a workable way to organize generation and revision. They do not yet establish improved learning or a general solution to subjective judgment.

What I would reuse is the architecture: several candidate approaches, explicit goals, executable checks, comparative evaluation, and a record of what each revision changed. The model supplies proposals. The workflow supplies opportunities to find out where those proposals fail.

The next useful test is against a fixed-budget baseline, with independent reviewers and learners who have not seen the material. If the evolved demo produces better explanations and better transfer to a new problem, we have evidence that the extra search bought something worth having.

That is the autonomy I want: longer stretches of useful work between human interventions, with enough evidence left behind to understand the result.

References & Further Reading

1. OPRO (LLMs as Optimizers): Large Language Models as Optimizers (Yang et al., ICLR 2024). Using LLMs to optimize without gradients.

2. Theory of Mind in LLMs (Strachan et al.): Testing theory of mind in large language models and humans (Nature Human Behaviour, 2024). GPT-4 vs humans on ToM tasks.

3. Theory of Mind in LLMs (Kosinski): Evaluating large language models in theory of mind tasks (PNAS, 2024). GPT-4 solving 75% of false-belief tasks.

4. Whiteboard-of-Thought Prompting: Whiteboard-of-Thought (2024). LLMs drawing reasoning steps as images.

5. Reward Hacking: Reward Hacking in RL. How proxy objectives can be exploited.

6. METR Task Horizons: Measuring AI Ability to Complete Long Tasks (Kwa & West et al., 2025). Historical software-task horizon measurements reported in March 2025.

7. Decision Transformer: Decision Transformer (Chen et al., NeurIPS 2021). RL as sequence modeling.

8. AlphaEvolve: AlphaEvolve. DeepMind's evolutionary coding agent.

9. Human Compatible: Russell, Stuart. Human Compatible: Artificial Intelligence and the Problem of Control (2019). A discussion of objectives, uncertainty, and human control.

10. A Pattern Language: Alexander, Christopher. A Pattern Language (1977). The original pattern encyclopedia.

11. Part 1: Agent Autonomy - Part 1: Algorithmic Problems. The foundation.