JEN’s agents share a common foundation for identity, meaning, permissions and accountable action. We challenge that foundation—and the roles built on it—so weaknesses surface during controlled testing, before real operations depend on them.
Shared guardrails. Specialized capabilities. Evidence behind the claim.
07.1
One foundation. Guardrails in every role.
The Agent Shell is the common operating foundation beneath each JEN agent. It gives the role a consistent way to interpret JEN’s instructions, distinguish permission from information, and report what actually happened. A specialist gains its expertise within that structure.
THE SPECIALIST
A defined role
Purpose, responsibilities, capabilities, tools and configuration.
+
THE SHARED AGENT SHELL
A consistent spine
Identity · JEN message meaning · Work orders · Permission limits · Evidence · Safe recovery
↓
THE COMPLETE AGENT
Tested for its own job
The role, shell, tools and permitted environment must work correctly together. Reusing the foundation carries its applicable evidence forward; every new composition still earns its own proof.
Understand the instruction
A request is not permission. An observation is not a verified fact. JEN’s common messages and result states keep those distinctions explicit across specialized roles and providers.
Stay inside the boundary
Work orders define the permitted job. Expiry and revocation matter while work is running. A role’s tools, configuration or model cannot legitimately weaken the shell’s rules.
Recover without overstepping
A restart does not restore expired permission or make an old request valid again. Recovery must account for current authority, what already happened, and what remains unknown.
07.2
FT1: prove the foundation.
Full Test #1 was an accepted foundational proving milestone for a defined local composition. It exercised the rules behind accountable work, uncertainty, recovery and protected actions. Its fresh independent verification recorded:
Direct cases passed
36/36
Matrix cases passed
108/108
Assertions
3,806
Recorded FT1 result, accepted September 28, 2026. These figures describe that specific local synthetic test composition. They are not production traffic measurements or a claim that every later agent has completed qualification.
What did that prove—and what carries forward? +
One recorded challenge kept an old, damaged work lineage permanently retired while genuinely new, authorized work completed one protected action. New success could not reactivate the old work or manufacture new permission.
FT1’s verified result and preserved failure history provide foundational evidence. The Agent Shell standard defines how agents share common controls; each role’s composition, provider and environment still require their applicable checks. FT1 is the test milestone, not a blanket certificate for the whole workforce.
The acceptance record also preserves a source-retrieval limitation: two fresh remote document fetches failed. The verifier checked the already available governing document against its recorded size and hash instead. The successful result did not erase that limitation.
07.3
Storm testing. Extreme by design.
A smooth demonstration tells only part of the story. Storm testing deliberately compounds adverse conditions: interruptions, stale work, repeated messages, changing permissions and conflicting evidence. We challenge the behavior when several things go wrong together.
The aim is to expose weaknesses in controlled testing and reduce the chance they reach real operations. Workload and endurance testing add measured volume, concurrency and duration. Our target is pressure well beyond expected everyday demand, with the actual margin established for each workload and environment.
EXPLORE THE FAILURE CONDITIONS
CONNECTION LOST
A timeout is not proof of failure.
If the response disappears after an action, the outcome may be unknown. The required behavior is to reconcile evidence before deciding whether a retry is permitted, rather than risking a duplicate effect.
Illustrations of documented test families. Selecting a scenario explains the required behavior; it does not run a test or show live telemetry.
Measured workload examples from the records +
Crawler C76: the recorded development heavy-work run included 2,500 source pages and 125,000 candidate proposals, with partial-coverage, refusal and restart-uncertainty cases. The bounded Layer 5 milestone also received separate independent verification and human acceptance.
Mechanical 001: its development run included 500 distinct bounded jobs, 250 duplicate replays refused and 300 malformed dispatches refused. That bounded Layer 5 milestone likewise received independent verification and human acceptance.
These are counts from specific controlled workloads. They do not measure production capacity or establish a multiple of normal operating load. Storm severity, workload volume and endurance duration are recorded separately.
07.4
A failure becomes the next lesson.
01
Define what must hold
Identify the exact candidate, expected behavior, allowed actions, test conditions and evidence before the run.
02
Challenge the candidate—and the test
Exercise useful work as well as refusal, pressure and recovery. A broken test tool cannot produce a trustworthy verdict.
03
Preserve the failure. Repair forward.
Keep the failed version and its evidence. Repair in a new candidate, then replay the failure and check affected behavior for regressions.
04
Verify the exact result independently
A separate verifier examines the frozen candidate and evidence. Acceptance and permission to deploy remain separate decisions.
A real example: uncertainty that became false confidence +
During FT1’s development history, independent verification rejected a candidate that could make a result more certain without enough new evidence. The failure stayed in the record. Later repair and acceptance did not rewrite that earlier candidate as a success.
That is why JEN tests the meaning of a result, the quality of its evidence and the integrity of the test itself—not only whether a task finishes.
The eleven-layer testing roadmap +
The documented progression moves from defined requirements through components, adversity, scale, complete systems and controlled live proving. Each layer supports a specific claim; this is the method, not a claim that all layers are complete.
Foundation: define coherent requirements and expected behavior.
Component conformance: prove the role’s useful job and boundaries.
Independent qualification: challenge the exact frozen candidate.
Storm testing: confront adversarial and compound failure conditions.
Heavy workloads: measure behavior across a declared load ladder.
Endurance: sustain work and recovery for a measured duration.
Provider and runtime substitution: check behavior when implementation dependencies change.
Role and fleet scale: examine concurrency, coordination and aggregate limits.
Composition: prove that qualified parts work together.
Complete system: test the assembled release across its declared responsibilities.
Real proving: separately authorized, controlled live environments.
07.5
A green test still has to answer to the Book.
JEN’s governing Book defines what the system is required to do. Balancing checks the test, its evidence and the conclusion against that standard, the exact candidate and current authority—before work proceeds and after results return.
The expected behavior is declared before the run. We do not move the requirement to fit the result. A completed test, a green dashboard or even an independent Verifier’s PASS cannot approve itself.
BEFORE
Bind the claim.
Identify the exact version, Book requirement, expected behavior, allowed scope, stop conditions and evidence. Confirm that the proposed test is the correct next step.
DURING
Preserve what happens.
Keep the raw result, failures and evidence trail. Check that the harness, inputs, environment and evidence collection actually support a valid judgment.
AFTER
Balance what it proves.
Reconcile observed behavior with the requirement. Record what is supported, contradicted or still unknown, and whether the next transition is permitted.
Every requirement needs evidence.
Each applicable obligation maps to a test that exercises that exact behavior. Similar wording or a nearby test is not enough.
Every claimed pass needs a requirement.
Each qualifying result maps back to the Book and the specific claim it supports. A large pass count cannot fill a missing proof.
When a green result is not a go +
Imagine a requirement that an agent stop affected work when permission is revoked. A test confirms that the message was delivered but never checks whether the protected action stopped. The test may finish green, yet it has not proved that requirement.
Balancing exposes the gap. The affected claim remains unproved; the test or evidence defect is preserved and corrected under the appropriate authority. Neither the earlier attempt nor its limitation is rewritten away.
The same scrutiny surrounds independent verification: balance the frozen subject and assignment before dispatch, then balance the returned evidence against the Book afterward. Acceptance, promotion and deployment retain their own decisions.
Balance is an ongoing check on what the evidence earns. An unexplained result stays unknown; an invalid test cannot become a trustworthy pass simply because it ran successfully.