Self Improving Loops with Profit at the End

The market can lag the public facts

Information asymmetry is not always secret information. Often, the useful gap is simpler. A fact is public, but the market has not priced it yet.

That is the case this article studies. A prediction market shows Alibaba as the clear favorite. At the same time, Z.ai has a new model with strong outside benchmark signals. The open question is whether those signals will move the exact Arena leaderboard that resolves the market before the check time.

A person can find that gap once. A cloud agent can keep checking whether the gap still exists.

This is the same move the strongest cloud agent systems are making in software. A local assistant helps while a person is present. A cloud agent keeps working after the laptop closes. It has a browser, files, tools, memory, schedules, and a review path. That makes it useful for live knowledge work, not just coding.

The contract creates the workflow

The case is a Polymarket market called Best Chinese AI Company end of July. The market resolves on July 31, 2026 at 12:00 PM ET. The rules say the winner is the company that owns the highest ranked model among primarily Chinese companies on Arena Text Overall, with style control off.

On June 29, 2026, the live Polymarket page showed Alibaba at 89 percent and Z.ai at 5 percent. It showed about $36,764 in total volume. That is a strong consensus price, but it is a thin market.

The rule is the workflow. The agent does not ask which company is best in general. It asks which company owns the highest ranked Chinese model on the exact Arena table at the exact time.

That difference matters. External benchmarks can explain why Z.ai may be underpriced, but they do not resolve the market. The agent has to track both the contract source and the outside signal.

The Z.ai signal is real, but it needs the right check

Z.ai released GLM-5.2 in mid June. Arena added GLM-5.2 to Text and Code leaderboards on June 16, 2026. Arena had added Qwen3.7-Max-Preview to Text and Vision leaderboards on May 14, 2026.

Artificial Analysis published a stronger external signal. On June 16, 2026, it said GLM-5.2 was the leading open weights model on its Intelligence Index v4.1, with a score of 51. It put MiniMax-M3 at 44, DeepSeek V4 Pro at 44, and Kimi K2.6 at 43.

Artificial Analysis also reported that GLM-5.2 has 744B total parameters, 40B active parameters, an MIT license, and a 1M token context window. Z.ai describes the model as built for long-horizon tasks, with a 1M token context and stronger coding with flexible effort.

OpenLM's Chatbot Arena+ snapshot showed GLM-5.2 at 1488 and Qwen3.7-Max at 1486. That is useful signal, but it is secondary. Polymarket resolves from Arena directly.

The direct Arena Text Overall page checked for this article still showed Qwen3.7-Max-Preview above GLM-5.2. Qwen was rank 16 at 1475 plus or minus 10. GLM-5.2 was rank 26 at 1470 plus or minus 7. GLM-5.1 was rank 19 at 1473 plus or minus 5.

That does not kill the Z.ai thesis. It defines it. The thesis is that external quality signals, GLM-5.2 vote growth, and a thin prediction market may move before the final July 31 Arena snapshot. The agent must monitor that thesis instead of assuming it is already true.

A three-part loop: monitor, trace, improve

The useful shift is not only that an agent runs somewhere else. The useful shift is that work can start from Slack, Linear, a schedule, a CLI, an API, or a web app, then continue in a remote environment with its own tools, and preserve the full trace of what it did.

For this market workflow, that means three pillars working together.

First, stay close to the source. The agent watches the exact pages that decide the outcome. It does not summarize from memory. It opens the browser, reads the leaderboard rows, saves the screenshots, and records the prices.

Second, build the system so production creates evidence. Every run captures more than inputs and outputs. It captures the full path from source page to extracted value to scenario model to proposed action. That trace is what makes the work auditable.

Third, create an improvement loop. Once production issues are visible and structured, they become findings, evals, and scoped tasks for the next run. A cropped screenshot becomes a screenshot quality check. An overconfident thesis becomes a confidence calibration eval. A missed model release becomes a new source to watch.

This is the same pattern that makes self-improving agents powerful in any domain. The product must make production failures visible. The trace must show where the miss happened. The eval must give the agent a hill to climb. The improvement must be tested before it changes the workflow.

The report improves as the world changes

The output is not a one time memo. It is a live report.

Each run saves the exact market price, source links, screenshots, leaderboard rows, transcript excerpts, and current probability scenarios. If the Arena table changes, the report changes. If Artificial Analysis updates a score, the report changes. If Z.ai or Qwen ships a new model, the report changes.

The report also keeps the old state. That matters because a trading decision should be auditable. A reviewer should be able to see what the agent knew, what changed, and why the system asked to add, reduce, or exit.

The screenshots in this article show that loop in action. The agent opens the market, checks the resolution source, reviews external benchmarks, builds the document, asks a validator to inspect the evidence, compiles the full summary, deepens the analysis with scenario modeling, and then integrates lessons from prior research into the current thesis.

Each step leaves a trace. Each trace becomes part of the report. Each report becomes the baseline for the next run.

For this market, the expert correction might be a human rejecting an overconfident Z.ai thesis. It might be the validator catching a cropped screenshot. It might be the official leaderboard moving against the trade. Each correction improves the next run.

The scheduled Opulent agent setup

Scheduled sessions are the backbone of this workflow. An Opulent scheduled session runs automatically on a recurring schedule or as a one-time run at a specific date and time. You give it a prompt, a frequency, and a runbook, and it runs whether or not anyone has a laptop open.

These agents do not run sequentially in one session. They run as managed parallel sessions, each in its own isolated workspace. A coordinator session scopes the work, monitors progress, resolves conflicts, and compiles results. It can spin up child sessions with specific prompts, runbooks, and compute limits. It can message running sessions with follow-up instructions. It can put a stuck session to sleep or terminate it. It can schedule a message to itself to check back on long-running work.

The first agent is the market watcher. It runs every 15 minutes. It records Polymarket prices, spreads, depth, volume, comments, and rule text. It saves a screenshot when the rules or displayed odds change.

The second agent is the resolution watcher. It runs every hour. It checks Arena Text Overall with style control off. It records Rank, score, confidence interval, votes, price, context length, and lab for the Chinese candidates.

The third agent is the external signal watcher. It runs every six hours. It checks Artificial Analysis, Arena changelog, Z.ai, Qwen, DeepSeek, Moonshot, MiniMax, Xiaomi, Baidu, Tencent, and ByteDance release pages.

The fourth agent is the edge model. It turns the evidence into scenarios. One scenario uses only the current Arena table. One scenario weights Arena trend and vote growth. One scenario adds external benchmarks and release momentum.

The fifth agent is the document agent. It keeps the transcript, source list, screenshots, and citation history in one evolving report.

The sixth agent is the validator. It checks the report against the screenshots and source pages. It flags cropped screenshots, missing citations, stale prices, and claims that are stronger than the evidence. The validator is a separate agent from the one that gathered the evidence, because an agent grading its own work tends to praise it. The validator defaults to doubt and verifies by acting, not just reading.

The seventh agent is the execution agent. It cannot act until the policy check passes. It can use browser, API, CLI, or service access to Polymarket, but only through a wallet provider with allowlisted markets, spend caps, loss caps, and revocable keys.

Every trade or proposed size change writes an evidence packet. The packet includes the source URLs, screenshots, quote time, market price, fair value scenarios, liquidity check, risk reason, and approver.

A persistent agent that monitors and routes

The monitoring layer does not need a human to start each check. Opulent can run a persistent agent that watches a channel, a feed, or a schedule and automatically triages what needs attention.

In a software team, that means a persistent agent monitors a Slack channel for bug reports, filters noise, detects duplicates, and spawns focused sub-sessions to investigate each issue. It tags the right code owner. It posts a diagnosis in the thread. It learns from corrections when someone says that is not my area.

For this market workflow, the same pattern becomes a persistent agent that monitors the Polymarket page, the Arena leaderboard, and the release feeds. It filters noise. It detects when a source page changes. It spawns focused sub-sessions to verify the change, update the report, and assess whether the thesis got stronger or weaker.

The agent has long-term memory. It accumulates context over time through a shared scratchpad. It tracks what it already checked, what changed, and what it should check next. It deduplicates repeated signals so the report does not fill with the same alert. It routes findings to the right reviewer or to the execution agent inside policy.

This is the difference between a cron job and a monitoring system. A cron job runs on a schedule. A persistent triage agent runs on a schedule, but it also remembers, deduplicates, routes, and learns.

Repeated work becomes a reusable procedure

A runbook encodes a repeated workflow as a file. Once written, the agent follows it reliably every time. You write the procedure once, and the agent executes it consistently across every run.

For this market, the runbook says: open the Polymarket page, save the price and volume, open the Arena leaderboard, save the rank rows for Chinese candidates, open Artificial Analysis, save the comparison charts, write the findings to the document, ask the validator to check the evidence, and propose an action only if the policy check passes.

Runbooks can be refined live. As you run a new runbook, you identify opportunities to improve the instructions so the agent completes the task more reliably. You edit the runbook, run it again, and compare the results. Over time, the runbook becomes the standard for how this workflow should run.

A runbook can be attached to a scheduled session. That means every time the schedule fires, the agent follows the same procedure with the same checks and the same evidence requirements. The runbook ensures consistent behavior across executions, even as the underlying data changes.

Runbooks can also be shared. A trading runbook written for this Polymarket can be adapted for another prediction market, another leaderboard, or another information asymmetry. The structure stays the same. The sources and rules change.

Context that compounds across runs

Knowledge is the standing context the agent can reference in any session. It is the bank of tips, instructions, and prior findings that the agent recalls when its current work is related.

For this market, knowledge includes the resolution rule, the list of Chinese AI companies to track, the benchmark sources to check, the wallet policy, the risk limits, and the lessons from prior runs.

Knowledge is not loaded all at once. The agent retrieves it when relevant. If the agent is checking the Arena leaderboard, it pulls the knowledge item about how Arena ranks models. If the agent is assessing a new Z.ai release, it pulls the knowledge item about GLM model naming conventions and release patterns.

The agent also suggests new knowledge from its own work. After a session, it may suggest remembering that a particular source page changes format on weekends, or that a particular market has thin liquidity after midnight. You edit the suggestion before saving, or dismiss it if it is not useful.

Over time, the knowledge base becomes the institutional memory of the workflow. New sessions start with the accumulated context of every prior run. That is what makes the system improve, not just repeat.

Procedures that teach the agent what to do

Skills are reusable procedures committed as files. They teach the agent how to do something specific, step by step, so it does not have to figure out the workflow from scratch every session.

For this market, skills include: how to verify a Polymarket market page, how to extract Arena leaderboard rows, how to compare benchmark scores across sources, how to write an evidence packet, and how to check wallet policy before execution.

The agent can discover skills automatically. After it tests a workflow or learns something new about the setup, it can suggest creating or updating a skill to capture that knowledge. You review the proposed skill, edit it, and commit it. Over time, the agent builds up a library of skills about how to run, verify, and execute this workflow.

Skills can restrict what the agent is allowed to do. A verification skill can limit the agent to read-only tools, so it can inspect evidence without taking action. An execution skill can require wallet policy checks before any trade. This is how skills become part of the control surface, not just the instruction surface.

Skills follow an open standard. The same skill files work across multiple agent tools. That means a skill written for this workflow is not locked into one platform. It is a portable asset.

How the network of agents self-updates

The most important property of this system is that it does not just repeat. It improves. And it does not just improve one workflow. It evolves the network of agents across systems.

Here is how that works in practice.

When the validator catches a cropped screenshot, that correction becomes a structured finding. The finding becomes an eval: does the screenshot include the full leaderboard table? The eval becomes a scoped task: update the screenshot skill to scroll the page before capturing. The updated skill is saved back to the knowledge base. The next run uses the improved skill automatically.

When the executor rejects an overconfident thesis, that correction becomes a calibration eval. The edge model agent is updated to weight external benchmarks less heavily when the official source has not moved. The next run produces more conservative scenarios.

When a new model release is missed because the agent was not watching the right feed, that gap becomes a new source to monitor. The external signal watcher is updated. The knowledge base records the new source. The next run checks it.

Session analysis accelerates this. A session that used far more compute than expected can be examined to find where the agent spent its time, what dead ends it tried, and how the prompt should be revised. A session that succeeded can be analyzed to extract the pattern that worked. Multiple sessions can be compared to identify what separates a good run from a bad one.

Runbooks improve through the same mechanism. A runbook that keeps failing on a specific edge case is compared against sessions where it succeeded. The system proposes a targeted update to handle the case it was missing. The improved runbook is saved and every scheduled session that uses it gets the fix on the next run.

Each correction flows through the same loop. The trace shows what happened. The eval defines what better looks like. The improvement is tested before it ships. The knowledge base saves the lesson. The next run is better.

This is not a single agent getting smarter. It is a network of agents that share a knowledge base, a set of skills, a library of runbooks, and a history of traces. When one agent learns something, the knowledge is available to every other agent in the network. When one runbook is refined, the improvement propagates to every scheduled session that uses it.

Explore and exploit other opportunities

The self-improving loop does not stop at one market. The same knowledge, skills, and runbooks can be applied to other information asymmetries.

The agent that learned to track Arena leaderboards can track any benchmark leaderboard. The agent that learned to assess prediction market odds can assess any contract with a public resolution rule. The runbook that encodes the monitor-trace-improve loop can be adapted for any domain where public facts lag market prices.

This creates a recursive explore and exploit cycle. The system exploits the current opportunity by running the scheduled loop on the Z.ai market. It explores new opportunities by applying the same monitoring pattern to other markets, other leaderboards, and other release schedules.

When the agent finds a new asymmetry, it saves the finding to the knowledge base. The finding includes the market, the rule, the signal, the evidence, and the proposed action. The executor can review it, approve it, or dismiss it. If approved, a new scheduled session is created with the relevant runbook and skills attached.

Over time, the system builds a portfolio of monitored opportunities. Each one runs its own scheduled loop. Each one contributes findings to the shared knowledge base. Each one benefits from improvements made in any other loop.

The executor stays in control. The system can be configured to document insights to the executor at whatever frequency is desired: a daily digest, a real-time alert, or a weekly summary. The executor can set the approval threshold for each opportunity. The executor can revoke wallet access at any time.

The scale is not limited by the number of people. It is limited by the quality of the monitoring loops, the depth of the knowledge base, and the discipline of the controls. That is what makes the system cohesive at scale. Every agent follows the same loop. Every loop writes to the same knowledge base. Every improvement propagates to every agent.

Three channels that make the agent better over time

The self-improving loop is not a single mechanism. It is three channels feeding the same knowledge base. Each channel contributes a different kind of learning. Together they explain why the system gets better at execution and at finding new opportunities to exploit.

The first channel is provided context. Knowledge entries, skills, and runbooks persist across sessions and compound. The agent does not start from scratch each run. It starts with the resolution rule, the source list, the wallet policy, the benchmark methodology, the lessons from prior runs, and the procedures for how to verify each piece of evidence. Context is what the agent knows before it does any work. The more context the system accumulates, the less time each run spends rediscovering what a previous run already figured out.

The second channel is feedback. Session analysis turns outcomes into structured learnings. When a session fails, the system identifies where it went wrong and extracts a pattern. When a session succeeds, the system identifies what made it work. When a runbook fails on a specific edge case, comparing failed sessions to successful ones produces a targeted fix. Feedback is what the agent learns from its own results. The cleaner the trace, the sharper the feedback. The settlement price of a prediction market is the cleanest feedback of all, because it is not an opinion. It is the answer.

The third channel is self-exploration. The discovery move lets the agent find its own work rather than being handed a list. The automation triggers a skill, not a wall of instructions. The skill tells the agent what to look for, but the agent decides what is worth acting on this turn. The recursive explore-and-exploit cycle extends this further. The system exploits the current opportunity by running the scheduled loop. It explores new opportunities by applying the same monitoring pattern to other markets, other leaderboards, and other release schedules. When the agent finds a new asymmetry, it saves the finding to the knowledge base for review.

These three channels reinforce each other. Context gives the agent a head start. Feedback corrects its mistakes. Self-exploration expands its reach. A system with only context repeats what it knows. A system with only feedback improves slowly because it has no foundation. A system with only self-exploration discovers opportunities but cannot execute reliably. The combination is what makes the loop compound.

The loop engineering framework calls this the four-layer stack. Prompt engineering minds the words. Context engineering minds what goes in the window. Harness engineering arms a single run. Loop engineering makes it run itself over and over. Each layer up, the unit of concern grows one size. The loop is the layer that removes the human from the position of doing the work and puts the human in the position of designing the system that does it instead.

That shift is what makes the three learning channels possible. A human in the loop cannot provide context, feedback, and self-exploration at machine speed. A human outside the loop, who has built the knowledge base, the skills, the runbooks, the schedules, and the control surface, can let the system learn while they sleep and review what it learned in the morning.

Autonomy needs policy before wallet access

This kind of agent should not have open wallet access. The agent should have a narrow policy.

A new market requires human approval. A size increase above the preset threshold requires human approval. A market must be allowlisted before the agent can trade it. The wallet must have a maximum spend per market and a maximum loss per day.

The agent should be able to reduce or exit within policy when the thesis weakens. It should ask for approval before adding size. That keeps autonomy useful without turning it into unsupervised risk.

The system should also log every blocked action. A blocked action is useful data. It shows where the agent wanted to act and why the policy stopped it.

This is not financial advice. It is a design pattern for public information, explicit rules, and controlled execution.

When the agent should add, reduce, or exit

The agent should add only when the modeled edge increases and the market still offers enough liquidity. It should never add only because a price looks low.

It should reduce when the official Arena table moves against the thesis. It should reduce when GLM vote growth fails to close the gap. It should reduce when Alibaba ships a stronger Qwen model before the check time.

It should also reduce when price reaches the modeled fair value. A good trade can become a bad hold if the market catches up.

The strongest rule is simple. The agent sizes the position according to evidence quality, not conviction language. More sources, cleaner rule fit, tighter spreads, and stronger leaderboard movement can permit more size. Weak source fit or wider spreads should force less size.

The agent does not need a browser to place a trade

The monitoring layer uses a browser because the agent has to read pages, save screenshots, and verify that the displayed data matches the extracted values. The execution layer does not need a browser. It needs an API key, a managed wallet, and a set of REST calls that place orders without touching a UI.

That is what a machine payments interface provides. The agent registers once and receives a bearer token. It creates a managed wallet whose private key lives inside a secure enclave, never in the agent's code or in the platform's application servers. The wallet address is bound to the agent. Every swap, order, and position is scoped to that address.

For prediction markets, the interface mirrors what a human trader would do on the Polymarket website, but through structured HTTP calls. Browse markets by category. Inspect a market to see the question, outcomes, volume, and liquidity. Check the order book. Get the midpoint price. Place a buy or sell order with a price between zero and one, a size in shares, and a side. Cancel an open order. List positions. List orders.

The difference between browser automation and API access is the difference between a robot typing into a form and a system sending a signed message. The API path is faster, cheaper, more reliable, and easier to audit. Every call produces a structured response. Every order gets an ID. Every position has a status. There is no screenshot to verify, no page load to wait for, no selector to break when the site redesigns.

This matters for the self-improving loop. When the execution agent places an order through the API, the trace captures the exact request, the response, the order ID, and the fill status. When the validator checks the work, it can verify the order against the market price at quote time without opening a browser. When the next run reviews the trace, it can see whether the agent placed the order at the right price, at the right size, and within policy.

A skill that wraps the prediction market API

The execution layer should not be improvised. It should be a skill, a reusable procedure committed as a file, that teaches the agent exactly how to interact with the prediction market API.

The skill wraps the REST surface into bash scripts the agent can call. One script browses markets by category. One script inspects a specific market and returns the question, outcomes, volume, and liquidity. One script checks the order book. One script gets the midpoint price. One script places an order with a token ID, price, size, and side. One script cancels an order. One script lists open positions. One script lists orders.

The skill enforces the control surface. Before the order script runs, the skill checks that the market is on the allowlist. It checks that the order size is within the spend cap. It checks that the cumulative exposure is within the loss cap. If any check fails, the script exits with a structured error and the agent records the blocked action in the trace.

The skill also handles the lifecycle. Quotes expire in sixty seconds. The skill requests a fresh quote before every order. Rate limits apply. The skill honors the retry-after header and backs off. Credits meter paid endpoint usage. The skill checks the balance before placing an order that would cost credits.

This is how machine payments become part of the loop instead of a separate manual step. The agent gathers evidence through the browser. It scores the thesis through its edge model. It checks policy through the skill. It places the order through the API. It records the result in the trace. The validator checks the order against the evidence. The next run uses the trace to improve.

The skill is portable. The same bash scripts work inside a scheduled session, a CLI, an MCP client, or an agent-to-agent delegation. The skill does not depend on Opulent. It depends on the API. That means the execution layer can be tested independently of the monitoring layer, and swapped without rewriting the workflow.

From thesis to filled order to settled profit

The article has described the monitoring, the evidence, the controls, the API, and the skill. The part that makes it a loop with profit at the end is the execution sequence that closes the circle.

The sequence has six steps. Each step produces a structured record. Each record feeds the next run.

First, the edge model produces a scenario. The scenario says: buy Z.ai Yes shares at or below a specific price, with a specific size, on a specific market. The scenario includes the fair value estimate, the confidence level, the evidence sources, and the assumptions that would break the thesis.

Second, the policy check runs. The market is on the allowlist. The order size is within the spend cap. The cumulative exposure is within the daily loss cap. The wallet has enough balance. If any check fails, the agent records the blocked action and stops. The blocked action is useful data. It shows where the agent wanted to act and why the policy stopped it.

Third, the execution skill requests a fresh market price. The skill calls the prediction market API to get the current midpoint, the order book depth, and the spread. If the price has moved beyond the scenario's entry threshold, the agent does not chase. It records that the opportunity expired and waits for the next scheduled run.

Fourth, the skill places the order. It sends a buy request with the token ID, the price, the size, and the side. The API returns an order ID and a status. The order sits in the book until it fills, or it does not fill and the skill cancels it before the next run. The agent records the order ID, the fill price, the fill size, and the timestamp in the trace.

Fifth, the position is monitored. The scheduled watcher keeps running. Every fifteen minutes it checks the market price, the position value, and the distance to the modeled fair value. If the thesis weakens, the edge model produces a reduce or exit scenario. If the thesis strengthens and the policy allows, the edge model produces an add scenario. Every change goes through the same policy check and the same execution skill.

Sixth, the market resolves. The contract settles on July 31. If Z.ai owns the highest ranked Chinese model on Arena Text Overall at the check time, the Yes shares resolve to one dollar each. The position settles. The profit or loss is recorded. The full trace from first observation to final settlement becomes the most valuable eval data the system has.

That last step is what makes the loop self-improving in a way that monitoring alone cannot be. The system does not just learn whether its screenshots were good or its citations were complete. It learns whether its thesis was right. A winning trade confirms the edge model. A losing trade exposes where the reasoning broke. A blocked trade that would have won shows where the policy was too conservative. A blocked trade that would have lost shows where the policy earned its keep.

Each outcome becomes a labeled example. The label is not a reviewer's opinion. It is the settlement price. That is the cleanest training signal a prediction market workflow can produce. The agent does not need someone to tell it whether it was right. The market tells it.

This is a knowledge work loop with money at the end

The Opulent Factory article described a loop for software work. Triage, implement, verify, and reopen the loop when verification fails.

This market workflow has the same shape. Watch, score, approve, execute, and review. If the evidence changes, the loop runs again. If the policy blocks an action, the loop records why.

The important part is that the agent uses context the market does not fully share. The context includes the user's thesis, prior research, preferred sources, risk limits, wallet policy, and the exact contract rules.

That is why cloud agents change the economics of knowledge work. They can keep private context attached to public sources. They can run while the user is away. They can return with an action packet instead of a loose summary.

The earning mechanism is not magic. It is faster checking, better memory, cleaner evidence, and controlled action.

How to run this safely

Start by screenshotting the market rules and saving the rule text. The resolution rule is the contract.

Build the watcher before the trader. The first useful output is a reliable daily packet that shows the market price, the official leaderboard, external benchmark changes, and the risk state.

Write the runbook before the first scheduled session. The runbook encodes the procedure so every run follows the same checks.

Add knowledge items as you learn. The resolution rule, the source list, the wallet policy, and the lessons from each run all belong in the knowledge base.

Create skills for the repeated procedures. How to verify a market page, how to extract leaderboard rows, how to write an evidence packet. Each skill makes the next run more reliable.

Add the wallet only after the evidence packet is stable. Use an allowlist, spend caps, loss caps, approval thresholds, and revocable keys.

Run the agent in observe only mode before execution. Compare its proposed adds, reductions, and exits with human judgment.

Only then allow constrained execution. The agent should still show its work before every material action.

The market is not the product. The loop is

The Z.ai and Alibaba market is a useful case because the rule is public and the information gap is visible. Alibaba is priced as the clear favorite. Z.ai has strong external model signals. The final outcome depends on one Arena table at one time.

That is exactly the kind of situation where a cloud agent is useful. It can keep checking what changed. It can show whether the thesis got stronger or weaker. It can prepare action inside policy.

But the deeper point is that the loop does not end with this market. The knowledge, skills, and runbooks built here become the foundation for the next opportunity. The corrections from this run become the evals for the next. The network of agents evolves with every cycle.

Autonomous earning through information asymmetry starts as research. It becomes valuable when the research turns into a scheduled loop with evidence, controls, self-improvement, and a clear approval path. It becomes durable when the loop learns from itself and propagates those lessons across every opportunity it touches.