The title of this blog is tongue-in-cheek—the entirety of this project will involve research. I fully expect to encounter roadblocks on a daily basis, and the resulting cycle of constant problem solving is where I expect to see myself grow. That is one of the things I’m most excited about: at it’s core, this capstone is about problem solving and design thinking.
We've always (rightly) placed so much value on the hard skills: knowing the right coding languages, properly using components and variables in Figma, grasping which filetypes are meant for what. But, as we see industries and job roles change, I believe that a person’s ability to plan, adapt, and truly think will all the more define his or her aptitude. Creativity (another word for problem solving, in my book) remains the skill behind any other marketable skill. A great software developer, data engineer, UI designer, and graphic design whiz all have creativity at their core, expressed in different ways. This is why, although my capstone wears the mask of an engineering project, I see it as a problem fit for a Visualization student. This major is meant to build thinkers with a variety of skillsets, and the greatest lesson that I’ve learned through the art, the sculptural projects, the 3D modeling, and the rendering, is that the best way to produce something you’re proud of is to simply get creative, whether or not the medium is within your comfort zone of practiced hard skills.
Anyways, let me dig in to the research progress I’ve made recently. In the last two weeks, I have vastly expanded my vocabulary to include the lingo that the SWEs on X are throwing around at one another. Now I know that, while I originally described my project as a loop engineering project, it’s actually taking things a step further: this is a graph engineering project. Graph engineering involves setting up the agentic loops themselves into systems that can complete tasks such as shipping software. Where a loop involves one or more agents working in a cycle to complete a mini-task, a graph can structure one or more loops to encompass a broader process. (If it sounds like a graph is just a loop of loops, then you've got it down.) The concept resembles the same node-and-link structure you see in TouchDesigner or Unreal Engine’s programming panels. Picture each node as an agent, and the links between them as the flow of tasks between different agents with different roles. The entire structure is your graph. In light of this, I can better describe my goal with this project as this: create a software that lets the user build out graphs of agents. In this way, it’s a UX project. I am designing a software that lets users engineer graphs.
I’ve spent my research phase building up my own understanding of the agentic engineering world today. In doing this, I’ve uncovered two valuable influences in Addy Osmani and Geoffrey Huntley. Osmani worked for Google for 14 years and, as of last Tuesday, started working for Anthropic. He is a widely cited author of articles about loop engineering. I discovered Geoffrey Huntley through one of Osmani’s articles. Geoffrey also outputs articles and helpful YouTube videos. He is credited with coining the term “Ralph Wiggum Loop” to describe a practice that involves writing a prompt to be given and re-given to an agent in a "study specifications, do the next task, and check your work" loop. The Ralph loop was, if not was a big part of, the beginning of all of this.
Above is a screenshot of some note-taking I've been up to as I've learned more about loop engineering and agents. I'll try to avoid lecturing, but first let me relate what I learned from Addy Osmani about the five critical components of an agentic loop.
Agentic Loops Require:
- Automations to trigger a loop's beginning.
- Distinct worktrees so that agents can work without conflicting with humans or other agents.
- Skills to direct agents how to specifically complete commonly-faced tasks.
- Plugins and Connectors to allow agents to interact with tools like your email, Figma, or Cloudflare.
- Sub-agents for different tasks and accountability.
When these five ingredients come together, you're able to create a potent program to accomplish a variety of tasks. Here's an idea of what an agentic loop looks like:
My project is to create a software that allows a user to make a loop like this, or to make something more complex (a graph of loops).
I realized that I would need some hands-on practice to better grasp these fundamentals, so I completed two exercises on this topic.
The first was Geoffrey Huntley's "How to Build a Coding Agent" workshop. I need to understand why and how agents work, seeing that this project will most likely be "solved" through orchestrator agents. In the context of my project, an orchestrator agent could actually be the glue that holds the loop or graph together and moves tasks from one subagent to the next. This workshop felt less like building my own agent, as its title promised, and more like receiving instructions from an expert in the field as I stitched together pre-made components of the agent. Still, this was an excellent starting point and allowed me to understand the bread and butter of what an agent truly is.
At its core, an agent is an LLM wrapped in context, instructions, and tools. The LLM is the brain. Specific instructions and information are provided to the agent so it can properly use tools to accomplish its task. What you see in the photo above from Huntley's workshop is the core loop of an agent: the agent gets input, uses the LLM to respond, possibly uses a tool to complete a task, and then delivers a response to the user. The five primitive tools that I connected to the agent in this workshop were a read file tool, a list files tool, a bash tool (which let the agent execute commands on the computer), and an edit file tool. Paired with the right LLM brain, these five simple tools equip an agent to code on your computer.
After this workshop, I wanted to try something that involved truly coding the agent rather than piecing together its anatomy. The tutorial I chose to follow next actually had zero likes and zero comments—that's how deep in the web we were. At the time of writing, it has one like. That was me. I chose this tutorial by Codernex on YouTube because it used the simple technologies that I'm already familiar with. Although its implementation of an agent was extremely rudimentary, using just Python and Ollama allowed me to understand what was happening on a deeper level. As I work through this project and use Claude to code, I'm grateful to have been able to implement a simple agent with my own hands so that I can grasp the more advanced implementations I encounter down the line.
This agent uses a locally-hosted LLM from Ollama, llama3.2, as its brain. It has two tools, which are actually functions: add and multiply. A simple loop works ensure you're getting the appropriate output and that the agent used our tools rather than going rogue and trying to add or multiply in its own strength. Following this tutorial helped cement my understanding that an agent is just a program that uses tools as functions to provide an output. Just as important, I had much-needed practice in communicating with the terminal and actually using Ollama's python library.
To sum things up, it has been an exciting and eye-opening beginning to my project. I'm both nervous and excited about what is coming next. Some specific tasks on my to-do list are to continue thinking through what a GUI for this software could look like and to deceive on how I'll package the software so it's accessible for users besides myself.