An AI consultancy declined a high-paying contract after technical discovery revealed that its software would be used for autonomous lethal decisions in warfare. The refusal did not settle where every AI company should draw its boundaries. It shows how a stated principle can become consequential when leaders and engineers must decide whether to accept a particular job.
When the scope became clear
The prospective client was developing automated hardware systems and wanted help designing software for remotely controlled and autonomous machinery. As the consultancy examined the technical requirements, the intended application came into focus: the software would make decisions about human targets in warfare. Compensation remained a significant part of the opportunity, but the team judged the intended use to be more important.
Both the leadership and engineering teams agreed to turn down the engagement. Their decision came toward the end of technical discovery, the stage in which a service firm examines what a customer needs before committing to the work. That timing matters: a project’s ethical stakes may become clear only after its technical purpose is understood.
▲ Technical review of a proposed project
The consultancy’s founder and CEO describes doing no harm to others as a central personal principle. In this case, that principle did not remain a general statement about responsible technology. The team applied it to a specific question: what decisions would its software make if the project went ahead?
How a consulting process shaped the decision
The firm was founded in June 2022 after its founder spent five years at Amazon Web Services (AWS). It works on cloud migrations, data and analytics, and artificial intelligence and machine learning. Machine learning refers to software trained to find patterns in data. Rather than supplying individual contractors, the consultancy assigns groups of its own engineers to projects organized around defined outcomes.
Its client discovery approach uses People, Process, Technology (PPT), a framework for examining the people involved, how work gets done, and the tools a project would require. That approach is designed to identify a customer’s underlying business need before engineers begin implementation. It can also make room for a question beyond technical feasibility: what will the finished system actually do?
The refusal shows why that question cannot always be answered by a broad project label such as automation. The team had to consider the role of its proposed software in the client’s larger system. Leadership and engineers reached the same conclusion, despite the contract’s revenue potential.
The founder’s view is that a company reflects the daily choices of the people in it, not just its stated identity. That is an ethical argument, rather than a measurable rule for evaluating every contract. Here, it describes the gap between saying a boundary exists and accepting the financial cost of observing it.
A limit on one use, not on every use
The founder favors actively shaping AI adoption rather than rejecting the technology altogether. The consultancy has also implemented an AI system for an emergency roadside assistance provider. That system sorts incoming calls so support can be dispatched faster during urgent incidents, potentially helping responders reach motorists sooner.
▲ A collective decision to decline
These two projects have different purposes. One uses AI to help route requests for assistance; the proposed weapons project would have used software for lethal decisions. The contrast explains the consultancy’s choice, but it does not establish a common standard for the industry. Other applications may raise harder questions about indirect effects, and good intentions alone may not reveal where a system’s use will lead.
Turning a principle into a contract review
The case suggests a review sequence for organizations choosing AI work. It should not be mistaken for a documented policy that every company already follows:
- Define the intended outcome. Establish what the client wants the finished system to accomplish before treating the engagement as an engineering task.
- Examine the system’s decision-making role. Ask what the software will decide and who may be affected, including through its use in a larger process.
- Bring technical and business judgment together. Engineers can clarify what they are being asked to build, while leaders must decide whether the company should take responsibility for building it.
- Make the boundary meaningful under financial pressure. Evaluate the intended use on its own terms, even when a contract offers substantial revenue.
This approach calls for slowing down enough to understand the request. It does not require claiming certainty about every downstream consequence of AI, which can be difficult to predict.
What the refusal leaves readers with
The consultancy accepted a financial trade-off after its team identified the proposed software’s role in lethal targeting. Its broader lesson is about decision-making, not a universal verdict on AI projects: ethical boundaries become practical when a team investigates the intended use and is willing to decline work that crosses its line. Organizations evaluating AI contracts can start by asking what the system will decide, involving the people who understand how it will work, and making the accept-or-decline decision only after those questions have clear answers.