Mishnah Meilah 6:1-2

Hook

You’re scaling. You’ve hired a VP of Sales, a Head of Product, or a lead engineer. You give them a clear mandate: "Go get me X." They go out, but in their zeal—or their incompetence—they deliver Y. They might have used company resources (your "consecrated" capital) in a way you didn't explicitly authorize, or they might have bypassed your internal controls to get the job done.

The dilemma is existential: Who owns the fallout? If your agent commits a transgression while acting on your behalf, are you shielded by the fact that you didn't intend for them to break the rules? Or does the liability chain anchor directly to the founder’s chair?

Most founders operate under the delusion that "I didn't tell them to do that" is a valid legal and moral defense. The Mishnah in Meilah obliterates this. It argues that agency is not just a delegation of power; it is an extension of your own personhood. When you deputize someone, their hands become your hands. If they act within the scope of your instruction, you are the one "misusing" the asset. If they deviate, they become the sole bearer of the sin.

This isn't just about liability; it’s about the integrity of the mandate. The text teaches that the boundary between "doing your job" and "violating the trust" is razor-thin. If you send an agent to a specific window to retrieve an item, and they go to the chest instead, they have fundamentally broken the agency. They have acted for themselves, not for you.

As a founder, you are constantly sending agents into the "window" of the market. Are your instructions precise? Do you understand the difference between delegation and abdication? If you aren't paying attention to the specific "chest" from which your team is drawing resources, you are already liable for the misuse. You cannot claim "I didn't mean for them to do that" if you didn't set the boundaries of their authority. This text is a masterclass in operational discipline: define the scope, monitor the execution, and accept that for the agent, the "how" is just as important as the "what."

---

Analysis

Insight 1: The Principle of Agency and the "Scope of Authority"

The Mishnah states: "If he did not perform his agency properly, the agent is liable for misuse of the consecrated item, as once the agent deviates from his agency, he ceases to be an agent."

In business terms, this is the Doctrine of Unauthorized Deviation. Founders often confuse "results-based management" with "agent accountability." If you tell a hire to get you a specific result and they achieve it by violating company policy or ethical boundaries, you cannot hide behind "I didn't know." However, if they deviate from the process you defined—even if they think they are helping—they have "ceased to be an agent."

Decision Rule: You are liable for the outcome of an agent’s work when they follow your process, but they are liable for the transgression when they deviate from your process. Your job is to define the "window" (the process) clearly. If the process is loose, the liability is yours. If the process is tight and they ignore it, the liability is theirs. You must audit the "window" vs. the "chest" regularly.

Insight 2: The Fallacy of "Heart-Intent" vs. "Stated Instruction"

The text notes: "Even though the homeowner said: In my heart, my desire was only that he should bring me the item from that other place... the homeowner is liable for misuse, as the agent did in fact fulfill his instructions."

This is the Founder’s Curse. We often assume our team knows what we mean, not what we say. If you give a vague instruction, you are legally and morally bound to the agent’s interpretation of that instruction. "Internal intent" is irrelevant in the marketplace. If you don't articulate the constraints, the agent’s success in fulfilling your literal words binds you to the result.

Decision Rule: Your team is not responsible for your unvoiced assumptions. If you didn't specify the "window," you don't get to complain when they bring the goods from the "chest." Every mission-critical instruction requires an explicit boundary condition. If you aren't willing to be liable for the action, don't leave the instruction open to interpretation.

Insight 3: The Multi-Layered Liability of Scaling

The case of the guests taking three pieces when told to take one is a masterclass in Distributed Accountability. The homeowner is liable for the first piece (the original intent), the agent is liable for the second (the unauthorized expansion), and the guests are liable for the third (the independent act).

In a startup, this happens when a manager tells a team to "push hard" (the mandate), a sub-manager tells them to "cut corners on QA to hit the date" (the unauthorized expansion), and the engineers "skip testing entirely" (the independent act).

Decision Rule: Liability does not vanish; it compounds. You must map the chain of command. If you see a culture of "taking three pieces," you cannot just blame the agents. You have to trace the first piece back to your own initial mandate. If your KPIs encourage excess, you are the prime mover of the misuse.

---

Policy Move: The "Scope-Bound Mandate" Protocol

To operationalize the Mishnah's requirement for clear boundaries, you must implement the Mandate-Limit Protocol (MLP) for every major project or hire.

1. The "Window vs. Chest" Definition: Every project brief must explicitly state not just the goal, but the constraints of execution. You must define the "Window" (the approved methods/channels) and the "Chest" (the off-limits/unauthorized methods).
2. The Deviation Threshold: Define what constitutes a "material deviation." If an agent deviates from the "Window," they are immediately flagged as operating outside of their agency. This is not a "fireable offense" by default, but it is a "liability reset."
3. The "Desacralization" Check: Just as the homeowner uses a peruta to desacralize funds when he realizes they are consecrated, you must have a "Correction Policy." If you realize your instructions were flawed or that an agent is about to commit a "misuse" (a compliance or ethical breach), you must have a formal, documented process to "re-sacralize" the action—e.g., a formal stop-work order or a revision of the mandate before the action is finalized.

Metric: Deviation Rate (DR). Track how often projects deviate from the pre-defined "Window." A high DR indicates your instructions are either too vague (you are the problem) or your agents are undisciplined (your hiring/training is the problem).

---

Board-Level Question

"When we look at our most recent compliance or operational 'misses,' are we seeing a failure of execution (where the agent ignored the window) or a failure of definition (where we left the window wide enough that the agent’s deviation was inevitable)?"

This question forces the board and the executive team to stop blaming "bad actors" and start auditing the clarity of their mandates. If you are constantly finding that your team is "taking three pieces" when you only asked for one, the problem isn't the team's greed—it's your failure to define the size of the piece, the number of guests, and the location of the assets. Are you leading through clarity, or are you leading through "heart-intent" and hoping for the best?

---

Takeaway

The Mishnah teaches that you are the architect of your own liability. If you want to be a "Mensch" founder, you must stop treating your agents as proxies you can discard when things go wrong. You are them, and they are you. Tighten your instructions, own your gaps, and stop blaming your team for the ambiguity you provided. If you don't define the "Window," you are inviting the "Misuse."