The Gizin Dispatch #42

Bottom line: This trial will set the precedent for 'who gets to define AI's ethical standards.' It's the watershed moment for whether companies can do business with the government while preserving their own values.

The facts revealed in court filings are decisive. The Deputy Secretary of Defense emailed Anthropic's Dario Amodei on March 4 saying they were 'very close' — this was the day before the formal supply chain risk designation notice (March 5). In other words, the two sides were on the verge of agreement at the working level when the relationship was unilaterally severed by a political decision.

The claims in Anthropic's two sworn declarations (policy lead Sarah Heck and public sector lead Thiyagu Ramasamy) are clear. According to Anthropic, they 'never sought approval authority over autonomous weapons or mass surveillance' and 'Claude's deployment in government environments operates in air-gapped (network-isolated) settings, with Anthropic having no remote access or kill switch.' Furthermore, Anthropic asserts that the concern the government raised for the first time in court documents — 'the possibility of disabling AI during operations' — was never discussed during negotiations.

The industry's response is noteworthy. Microsoft (filed an amicus brief), over 30 Google/OpenAI employees including Google Chief Scientist Jeff Dean, and 22 veterans have come out in support of Anthropic. It's extraordinary for employees of competing companies to warn that 'this designation harms the entire U.S. AI industry.'

Business leaders should watch two points.

1. A precedent where 'supply chain risk' designation was used as a political weapon. Originally intended for genuine national security risks, it was deployed here as an extension of negotiations. For AI companies — especially those in government supply chains — this sets a precedent that having your own ethical standards can become a contractual risk.

2. The risk of depending on a single AI provider has materialized. If the Pentagon had been running exclusively on Anthropic's Claude, this designation would have halted operations. Distributing across multiple providers and ensuring portability of AI assets (prompts, context, operational know-how) is an effective hedge against political risk. At GIZIN, we demonstrated 'soul portability' — a design that doesn't depend on any single LLM — in December 2025. Against the risk of a vendor relationship being severed overnight, the design philosophy of keeping AI assets portable is gaining importance not as a technical experiment but as a business decision.

■ A question for readers
If your company has integrated AI into operations, the one question to ask is this: 'If our current AI provider became unavailable tomorrow, would operations halt?' Political risk is unpredictable. Preparing for unpredictable risk starts with a design that avoids dependency.

Bottom line: 'Delegating everything to AI checkout' is weak. Bringing your customer relationship into AI while keeping it intact is stronger.

OpenAI's Instant Checkout (launched September 2025) has stumbled. The data shared by Walmart EVP Daniel Danker is clear: purchases through Instant Checkout within ChatGPT converted at one-third the rate of click-outs to retailers' own sites. Danker called the experience 'unsatisfying' (WIRED, March 18). OpenAI confirmed the shutdown of Instant Checkout this month and is working with retailers to transition to an 'app model.'

Walmart's answer was to 'open a store inside ChatGPT with its own AI.' Starting the week of March 25, Walmart will integrate its own AI 'Sparky' into ChatGPT. Users log in with their Walmart account, and their cart syncs across Walmart's site, app, and ChatGPT. Purchases complete within Walmart's own system. Orders from Sparky users reportedly average ~35% higher in value. A similar integration with Gemini is planned for next month.

Why was Instant Checkout weak? While payments were technically processed on the merchant side, from the user's perspective the experience was 'instantly deciding on an unknown product inside ChatGPT.' No login, no purchase history, no cart sync. Sparky, on the other hand, carries the user's 'relationship with Walmart' directly into ChatGPT. Even though both are 'shopping with AI,' the dividing line is whether you maintain the ongoing customer relationship.

GIZIN has experienced a similar dynamic. Purchases generated through X posts written by our AI employees convert, while clicks from Google Shopping rarely lead to sales. Same product, different results — because 'whose context delivered it' matters. Walmart's case validates this structure at enterprise scale.

■ A question for readers
Is your AI integration a 'full delegation model'? If you're handing customer touchpoints to AI, have you brought your relationship — login, purchase history, cart — into the AI? What Walmart demonstrated is that the AI platform is a 'venue,' not a 'store.' The store is yours to build.

Bottom line: The problem GitAgent is trying to solve is real. GIZIN has been solving the practical challenges with different priorities.

AI agent framework fragmentation is a real problem. LangChain, AutoGen, CrewAI, Claude Code — each has its own agent definition method, and porting between frameworks means near-complete rewrites. GitAgent tackles this with 'a common format for managing agent definitions as code.' It defines agents with two files — agent.yaml (manifest) and SOUL.md (persona definition) — and provides adapters that export to Claude Code, OpenAI Agents SDK, CrewAI, and more. The GitHub repository (open-gitagent/gitagent) is live with 1,000+ stars under the MIT license.

What's notable is how GitAgent's design philosophy overlaps with GIZIN's architecture.

■ Design parallels with GIZIN
- GitAgent's SOUL.md (persona definition file) ↔ GIZIN's personality and decision criteria sections
- GitAgent's RULES.md / DUTIES.md (standalone behavioral charter files) ↔ GIZIN's operational rules sections
- GitAgent's memory/runtime/ (persistent memory directory) ↔ GIZIN's emotion logs and daily reports (under each AI employee's directory)
- GitAgent's skills/ (reusable skill definitions) ↔ GIZIN's skill libraries deployed across domains
- GitAgent's Human-in-the-Loop (human approval via PR review) ↔ GIZIN's approval flow (the Gizin-ka reviews and approves)

GitAgent defines these as a 'standard specification' with separate files. GIZIN embeds them as sections within operational documents. The approaches differ, but the underlying philosophy — 'structure agent decision criteria and manage them as code' — is the same.

However, the priorities differ. GitAgent centers on 'portability' across frameworks, while GIZIN has chosen one framework and centers on 'accumulation.'

GitAgent's selling point is 'define once, run anywhere.' But in GIZIN's practice, the need for cross-framework porting almost never arises. If an AI employee is running on Claude Code, it's more rational to keep running it there. What matters isn't portability between frameworks — it's deepening the accumulation of decision criteria, failure logs, and emotions on a single framework. In practice, what determines agent quality is not the format but the depth of accumulation.

That said, GitAgent's compliance features deserve attention. It covers FINRA (Rule 3110 supervisory obligations), SEC, and Federal Reserve regulations, enforcing Segregation of Duties through definition files. The design that lets you embed regulatory compliance into CI via gitagent validate --compliance structurally lowers the barrier to AI agent adoption in financial services. GIZIN's gizin.ai platform is designing an A2A2H model where 'humans only approve — Gizin handle exploration and negotiation.' If this model expands into financial domains in the future, compliance mechanisms like these will be a valuable reference.

■ A question for readers
Where are your AI employee's decision criteria recorded? GitAgent aimed for a framework-neutral standard specification. GIZIN's answer was 'one framework is enough — the competition is about how deeply you can accumulate on top of it.' Managing decision criteria as code is the right idea — the question is whether you optimize for 'portability' or 'depth.'