# If Agents Are Going to Build Software, They Deserve Better Software Too. Point of View · 716 Ventures · July 2026 > If we need better workflows for humans working with agents, we should also be building better workflows for the agents themselves. ## The Logical Next Step In my [previous article](/articles/why-not-how), I argued that the problem isn't *how* — it's **why**. The more time I've spent building products alongside AI, the more I'm convinced that the quality of the output has less to do with the prompt itself and much more to do with whether the human and the agent have arrived at the **same understanding** of the problem before any work has begun. That realization led me somewhere I wasn't expecting, but in hindsight, it's the logical next step. If we need better workflows for humans working with agents, shouldn't we also be building better workflows for the **agents themselves**? ## The Wrong Environment The more I thought about it, the stranger our current tools started to feel. We ask agents to build high quality software while forcing them to work inside environments that weren't designed for them. We scatter important decisions across Slack, Linear, email, documentation, and chat conversations, then expect an agent to reconstruct the project well enough to produce consistent results. Sometimes it does. Sometimes it doesn't. When the quality varies, we tend to blame the model. I'm starting to think we're blaming the **wrong thing**. Imagine hiring a new engineer and giving them access to nothing but a terminal and a chat window. No project history. No ticket describing the work. No acceptance criteria. No record of why previous decisions were made. No structured review process. We wouldn't expect that person to consistently produce excellent work because we've learned, through decades of building software, that good engineering depends on much more than writing code. The environment matters, and that's exactly what **Vector Sigma** grew out of. ## Why Build Another One And look, I understand that there are eleventy billion of these now. Some people call them harnesses, others loop engineering, and some refer to the whole thing as "The Engineer". There's nothing wrong with any of them, but they don't operate how I want, based on the principles that I have been building out over the last year. So, like any good engineer I built something new. It's a disease, but I love it. ## Applying the Principles Let's talk about what applying the principles means in a practical sense: - Every piece of work starts with enough context to understand the problem instead of jumping straight into implementation. - The objective is clearly defined before anyone writes code. - Constraints, previous decisions, and completion criteria travel with the work instead of existing somewhere else. - Verification is built into the workflow rather than treated as something you remember to do after the fact. Those ideas probably sound familiar if you've been reading the articles or working through the skills library. That's *intentional*. The principles and skills are designed to help people become better collaborators with agents. Vector Sigma applies those same ideas to the agents themselves. Instead of expecting the model to figure out how you like to work, the environment encourages the behaviors that consistently lead to better software. That's the core really. Vector Sigma isn't trying to make the model smarter, it's trying to make the **workflow** smarter. ## Models Will Improve. Environments Must Too. This really matters because models will continue to improve — that's a given. The question is whether the environments we ask them to work inside improve at the same pace. When I think about the engineering practices we've developed over the last few decades, almost all of them exist for the same reason. Code reviews exist because they improve quality. Design reviews exist because they uncover problems before implementation. Testing exists because confidence isn't the same thing as correctness. We didn't invent those practices because they were interesting. We invented them because experience taught us they consistently produced better software. I think we're at a similar point with agentic development. We're still treating every interaction like an isolated conversation instead of part of a larger engineering system. The result is that every new task begins by reconstructing context, rediscovering constraints, and redefining success before any meaningful work can begin. That's not a model limitation, it's an **environment limitation**. ## What the Environment Should Already Know The environment should already know: - what the objective is, - why the work matters, - what constraints exist, - how success will be measured, - what happened before, - and how the result will be verified. Once those things exist, the conversation with the agent becomes dramatically simpler because the difficult thinking has already been done. That's how I think about Vector Sigma. It isn't another task tracker with AI bolted onto the side, it's an attempt to answer a question that I don't think our industry has spent enough time asking yet: **If agents are becoming legitimate participants in building software, what does the ideal working environment for an agent actually look like?** I don't think we're going to answer that question by adding another chatbot to existing software. I think we'll answer it by building environments that consistently help agents produce better work. That's what Vector Sigma is trying to become.