Daily Rambam Accelerated · Startup Mensch · On-Ramp

Mishneh Torah, Divorce 7-9

On-RampStartup MenschApril 23, 2026

Hook

In the high-velocity world of startups, "moving fast and breaking things" is often treated as a badge of honor. Founders are obsessed with velocity—shipping features, closing rounds, and capturing market share. But there is a silent, lethal risk in this pursuit: the fragility of your "paper trail" of trust. When a startup scales, legal and operational handoffs become the norm. You delegate authority to agents, remote teams, and intermediaries. The dilemma? How do you ensure that when you aren't in the room, the integrity of your core mission, your intellectual property, and your contractual obligations remain intact?

The Mishneh Torah (Divorce 7-9) deals with a high-stakes legal instrument: the get (bill of divorce). In a world where communication was slow and verification difficult, the Sages developed rigorous protocols for agents to ensure that the document, and the intent behind it, were authentic. If the agent failed to say, "It was written and signed in my presence," the entire legal status of a human life could be thrown into chaos. For a founder, this isn't just about religious law; it’s about the architecture of accountability. Are your processes designed to prevent "forgery" (misalignment) in your absence? When the distance between you and your execution team grows, does your trust rely on wishful thinking, or on verifiable, immutable protocols?

Analysis

Insight 1: Verification is an Operational Standard, Not a Suggestion

The text specifies that when an agent delivers a get in the diaspora, they must declare: "It was written and signed in my presence" (Halachah 7). Rambam notes that this was instituted by the Sages to prevent the woman from facing insurmountable difficulty in verifying signatures later.

Decision Rule: In business, never treat the "last mile" of a handoff as self-verifying. If you are delegating a mission-critical task—like a product launch, a term sheet negotiation, or a key client onboarding—you must mandate a "verification protocol." The agent must be able to confirm the origin and the validity of the work product. If your team cannot answer "How do we know this is authentic?" without you present, your delegation is flawed. Metric: Measure the "Verification Cycle Time"—the time it takes for an output to be validated by a second party before it reaches the end user. If this is zero, you are shipping risk.

Insight 2: The "Hate" Heuristic and Conflict of Interest

The Sages were remarkably cynical about human nature, noting that women who "presume hate each other" are not trusted as agents (Halachah 2). This is a masterclass in risk management regarding incentives.

Decision Rule: Your internal processes must account for the "internal competitor" or the "disincentivized agent." If you allow a team member with a potential conflict of interest (e.g., a salesperson who benefits from a deal that might harm company culture or long-term retention) to act as the sole conduit of information, you are inviting "forgery" (or data manipulation). Do not rely on the integrity of the agent if their incentives are misaligned. Build "conflict-aware workflows" where the agent’s potential for bias is checked by an independent witness or a secondary verification step.

Insight 3: Agency is Not Indefinite

The Mishneh Torah highlights that if an agent is hindered by forces beyond their control, they can appoint a second agent, but only under specific circumstances—often involving a court of law or public verification (Halachah 4, 12).

Decision Rule: Authority is not a blank check. When you delegate, you must define the "Scope of Substitution." Can your Head of Product appoint a consultant to rewrite the roadmap? Can your CTO delegate a security audit to an untested third party? If your delegation protocols don’t define how authority is transferred or replaced, you will face "authority drift." Every delegation of authority must include a "termination clause"—a specific point at which the agent must check back in with the principal (you) or a designated board/court. Metric: Audit your "Delegation Depth." If a task is three layers deep from the founder, it is likely being executed without the original intent.

Policy Move

The "Witnessed Hand-off" Policy

To minimize the risk of operational drift, implement a mandatory Verification Protocol for all "High-Impact Handoffs."

  1. Mandatory Declaration: Any agent or lead managing a cross-departmental handoff must submit a "Verification Memo" that includes the following:
    • Provenance: "I have verified the work was completed according to our core standards."
    • Integrity: "I certify that the inputs used were valid and current."
  2. Witness Requirement: For any decision that permanently alters a client contract, intellectual property, or significant capital allocation, the agent must involve a second, independent employee to "witness" the completion of the task.
  3. The "No-Speech" Clause: If an agent is unable to provide the Verification Memo (due to departure, sudden leave, or failure to follow protocol), the work product is automatically considered "void" and must be re-verified by an independent audit before it can be deployed.

This forces a culture of conscious completion. It prevents the "ghosting" of responsibility where a task is pushed forward despite missing components.

Board-Level Question

"When we look at our most critical operational dependencies—the handoffs between our engineering, sales, and legal teams—are we relying on the reputation of the people involved, or are we relying on a verifiable process that functions even if those people leave the company tomorrow? If our key lead for X left today, would we be able to prove the integrity of the last six months of their work, or would we find ourselves in the legal equivalent of a 'lost get'—an operational status that is in doubt?"

Takeaway

The Sages understood that in a complex, distributed world, trust is not a feeling; it is a procedure. The get is only as strong as the agent’s ability to prove its origin. Your startup’s success is only as robust as your ability to prove the origin, intent, and integrity of your decisions. Stop hoping your team "gets it" and start building the protocols that make it impossible for them not to. If you don't build the verification, you are the one responsible for the forgery.