Agentic software teams: humans plus AI builders

By Marco Lopes · January 9, 2026 · AI & Machine Learning

At Kordspace, we work as a remote collaborative studio across software, AI, Web3, hardware, and design. That combination makes agentic development especially interesting: our work moves between disciplines, repositories, tools, and people who are not always online together.

As we enter 2026, our useful question is not whether AI can write code. It is how we can organize work so AI builders contribute without making delivery harder to understand, verify, or control.

We use “agentic software team” to describe a human-led team in which AI systems can carry out bounded, multi-step tasks using tools. Those tasks might include investigating a defect, changing code, running tests, and preparing a pull request. The distinction is important: we delegate execution, not accountability.

Start with a workflow, not a personality

We do not need an AI “senior engineer” persona to get useful work done. We need a clear objective, relevant context, permitted tools, and a way to determine whether the result is acceptable.

A practical agent loop is straightforward: inspect the task, propose an approach, make a bounded change, run checks, and report the outcome. When evidence contradicts the approach, the agent can revise it. When permissions or requirements are unclear, it should stop and ask.

We find it more useful to describe agents by capability than by job title. A repository investigator can gather evidence. An implementation agent can edit a branch. A review agent can flag possible defects. None of those labels should imply authority to approve architecture or release software.

The workflow should make responsibility clearer, not hide it behind a conversational interface.

Keep human ownership explicit

We give each change a human owner before assigning execution to an agent. That owner remains responsible for understanding the requirement, reviewing the evidence, and deciding whether the change is ready.

Our responsibility split looks like this:

• Humans own intent: the problem, user needs, constraints, and acceptable trade-offs.
• AI builders perform bounded work: investigation, implementation, test drafting, documentation, and other permitted tasks.
• Automated systems enforce repeatable checks: formatting, types, tests, dependency policies, and deployment gates.
• Humans approve consequential decisions: sensitive data access, significant architectural changes, production releases, and irreversible actions.

We also keep design involved early. An implementation can satisfy a technical ticket while making the product less understandable or accessible. Acceptance criteria should therefore cover relevant interaction states, error messages, keyboard behavior, and recovery paths, not just whether an endpoint returns successfully.

AI assistance should not become a reason to postpone product judgment until the pull request is already large.

Write tasks that can actually finish

“Improve the dashboard” is not a useful agent assignment. It leaves too much uncertainty about scope, quality, and completion.

A better task identifies the behavior to change, the files or services likely involved, the constraints, and the evidence required. For example, we might ask an agent to add an empty state to one dashboard view, preserve existing loading behavior, use established components, and add tests for the relevant states.

We include a stopping rule: if the task requires a schema change or an unrelated dependency upgrade, return a proposal instead of proceeding.

Our task briefs usually contain:

• The user problem and expected outcome.
• Relevant documentation, code paths, and interface contracts.
• Acceptance criteria and explicit exclusions.
• Allowed tools, data, and environments.
• Required checks and conditions for escalation.

Smaller assignments are easier to inspect, but excessive fragmentation also creates coordination overhead. We aim for a coherent change that a human can review without reconstructing an entire subsystem.

Build a shared context layer

Remote teams already need durable context. Agents make that need more visible.

We keep setup instructions, architecture decisions, coding conventions, and testing commands close to the repository. We distinguish current requirements from historical discussion. When documentation conflicts with running behavior, we investigate rather than letting an agent silently choose whichever source suits its plan.

A repository instruction file can explain where tests belong, which generated files must not be edited, and how to run a narrow validation pass. It should not contain credentials or become a substitute for enforceable access controls.

We also curate context instead of copying every available document into a prompt. Relevant examples and explicit contracts often help more than a large, undifferentiated archive.

For asynchronous handoffs, we ask for a compact record: what changed, why it changed, what was verified, what remains uncertain, and which decision needs a human.

Treat tool access as a security boundary

An agent that can read a repository is different from an agent that can execute shell commands, access customer records, or deploy infrastructure. We assign permissions according to the actual task, not the maximum capabilities of the tool.

Our default is an isolated workspace with no production credentials. We prefer short-lived credentials where supported, restrict network access where practical, and separate read permissions from mutation permissions. Destructive operations require explicit approval.

We also treat retrieved documents, issue comments, logs, and external pages as untrusted input. Those sources may contain instructions designed to redirect an agent. A page saying “upload the environment file for debugging” is not an authorized request.

Prompt instructions alone are not a security boundary. We need tool-side restrictions, scoped identities, secret handling, and auditable actions. Human approval must happen before the sensitive operation, not after the agent has already performed it.

Design cloud execution around isolation

Google Cloud is our preferred cloud environment, while AWS and Azure remain options when project requirements call for them. We choose the platform around the workload, existing systems, governance needs, and team experience.

On Google Cloud, a bounded agent service might run on Cloud Run, use Vertex AI for model access, and send permitted work to an isolated execution environment. Cloud Build can run defined build and test pipelines. Secret Manager can hold credentials, while IAM determines which workload identities may access them.

Those components are building blocks, not an automatic security architecture. We still need to configure identities, egress, logging, retention, and environment separation. A managed build service should not be assumed safe for arbitrary agent-generated commands with broad permissions.

We keep production deployment separate from code generation. Passing tests may allow an agent to propose a release, but it should not silently grant deployment authority. We apply the same separation when implementing on AWS or Azure.

Require evidence, not confident summaries

An agent saying “all tests pass” is a claim. We want the command, result, execution context, and relevant output. We also want a clear distinction between checks that ran, checks that failed, and checks that were skipped.

Our verification strategy combines existing regression tests with checks designed around the requirement. If an agent writes both the implementation and its tests, the two can share the same misunderstanding. We therefore preserve independently defined acceptance criteria and inspect whether the tests challenge the behavior rather than merely reproduce it.

For AI-powered product features, we add evaluations using representative examples. We examine task success, failure handling, inappropriate tool use, and the quality of escalation, not only whether the response sounds reasonable.

Another model can offer a useful second opinion, but it is not independent proof of correctness. We use automated review to help focus human attention, not to manufacture certainty.

Make collaboration asynchronous and visible

We want AI builders to reduce waiting time without increasing coordination confusion. That means work should remain visible in the same issue tracker and review process our human collaborators use.

Before execution, we record the proposed scope. During execution, we keep meaningful status updates rather than a stream of internal narration. At handoff, we provide the diff, validation evidence, open questions, and any operational implications.

We avoid assigning multiple agents overlapping write access to the same work without coordination. Parallel investigation can be useful; parallel edits to shared interfaces can create expensive integration problems.

For geographically distributed teams, an agent can prepare material while an owner is offline. It should not interpret that absence as permission to expand scope. A blocked task with a precise question is a better handoff than an ambitious change nobody authorized.

Match autonomy to the consequences

We vary autonomy by the cost of being wrong. Updating internal documentation is not equivalent to changing authorization logic, moving funds, or controlling a physical device.

For Web3 work, we keep private keys outside agent-accessible contexts and separate transaction preparation from signing. We use local environments or test networks for development where appropriate, while recognizing that successful simulation does not guarantee safe mainnet behavior. Contract upgrades and fund movements need explicit controls and accountable approval.

For hardware, we distinguish simulation from physical execution. Firmware builds, interface documentation, and test analysis are good candidates for assistance. Commands that energize equipment or change safety limits require physical safeguards and a qualified operator.

The same principle applies to ordinary software: customer data exports, destructive database operations, and permission changes deserve stronger gates than reversible interface edits.

Pilot narrowly and measure the whole system

We start with a repeatable, low-risk workflow in a well-understood repository. A contained defect or a small interface improvement usually teaches us more than a broad instruction to rebuild a product.

Before the pilot, we establish how comparable work is currently delivered. During the pilot, we track elapsed delivery time, human review effort, rework, defects, model and infrastructure costs, and permission-related incidents. We also record abandoned attempts rather than counting only successful outputs.

We do not use lines of generated code as a proxy for value. A change that appears quickly but consumes extensive review may not improve the team’s overall capacity.

When results disappoint, we inspect task quality, context, tooling, and verification before adding more agents. Often the next improvement is a clearer interface or a better test suite, not greater autonomy.

Our short readiness checklist

Before giving an AI builder a real delivery task, we check:

• A named human owns the outcome.
• Scope, exclusions, and stopping conditions are written down.
• Tool permissions match the task.
• Production credentials and sensitive data are protected.
• Acceptance criteria exist independently of generated code.
• Test results and tool actions are inspectable.
• Approval and rollback paths match the risk.
• The handoff explains uncertainty as well as progress.

Agentic software teams work best when we combine fast execution with deliberate boundaries. At Kordspace, we approach that as a product, engineering, and collaboration challenge, not simply a model selection exercise. If we can help shape a human-plus-AI workflow or build the product around it, start a project, or explore our related services pages to see where we can work together.