As an agent fleet grows to 100, 1,000, and beyond, manually assigning work and checking progress agent by agent becomes impractical. We need to move up a level: define how the work should proceed, then let the platform coordinate execution. Loops describe how results are refined; graphs define dependencies and reveal work that can run in parallel. Combining them lets a fleet investigate several paths and revise the parts that need attention.

In this JAPAC Center of Excellence (CoE) exploration, we use scientific examples to examine these workflow patterns. OCI supplies the execution and persistent-workspace foundation, while our fleet software coordinates the work above it.

• Understand when to use a refinement loop, a dependency graph, or both.
• Connect these patterns to the OCI agent fleet infrastructure introduced in our first article.
• Explore mathematics, physics knowledge synthesis, and an open biology question without claiming customer outcomes or new scientific discoveries.

1. Background

Consider a research team preparing a technical report. One person checks the data, another tests a method, and another reviews the literature. Some work can happen at the same time; some must wait for earlier findings. When a reviewer finds a problem, the relevant work needs another pass. An agent fleet faces the same coordination problem: who can start now, what must they wait for, and what should they revise?

We chose scientific workflows as illustrative experiments, not as a customer case study or a production deployment. The math example records 69 completed tasks across 29 specialists and a client agent. A separate physics paper illustrates knowledge synthesis; biology remains an open-question workflow exploration. Our purpose is to investigate how an agent fleet might facilitate research and what must be verified before applying the approach to real business and research settings.

2. Loops, graphs, and their combination

Loops refine a result

A loop repeats work in response to feedback. An agent proposes an answer, a reviewer or executable test checks it, and the agent revises the answer if needed. For example, a mathematical construction can be tested and repaired until it passes a checker. The useful part is the feedback: repeating the same prompt without new evidence is not meaningful refinement.

Every loop needs a stopping rule. Stop when the acceptance criteria are met, the time or iteration budget is exhausted, or a person must resolve uncertainty. More iterations do not guarantee a better answer.

Graphs organize dependencies and expose parallel work

A dependency graph is a map of tasks and the inputs each task needs. A node represents a task; an arrow means that one task supplies an input to another. Data analysis and literature review can proceed independently, while a synthesis task waits for both. The graph helps a scheduler run ready tasks together instead of forcing all work through one long sequence.

This can make better use of available compute and reduce unnecessary waiting. The benefit depends on how much work is independent, the available capacity, and the cost of coordination. A graph does not by itself guarantee a speedup. Here, “graph” means a workflow dependency graph, not a graph database or graph-analysis algorithm.

Combine parallel investigation with targeted refinement

In practice, research often needs both. The bottom panel of Figure 1 combines an “Analyze / revise” branch with “Review literature.” Both feed “Synthesize and check,” which can send feedback back to the analysis branch before acceptance. After revision, dependent outputs must be refreshed; work that remains valid need not be repeated. This is the refinement loop shown within the larger dependency graph.

Figure 1. Loops refine; graphs organize dependencies and expose parallel work; the combined pattern directs refinement to the branch that needs it. These are conceptual workflows, not measured performance results.

Table 1. Choose the pattern by the work and its acceptance criteria, not by the number of agents.

A loop is itself representable as a graph with a cycle; the distinction here is practical, not a division into incompatible computing models. One agent may execute several tasks, and multiple agents may contribute to a single branch. To keep the process dependable, record the input and output versions, review decisions, and remaining budget. The controller must enforce limits and avoid having waiting agents occupy all the slots needed by their dependencies.

3. OCI infrastructure behind the workflow

Our first article reported 6,000 of 6,000 short, read-only requests completed without client retries across a persistent 1,000-agent fleet. That result demonstrated the fleet’s request path under the tested workload; this article explores the collaboration patterns above it.

The infrastructure from the first article supports different parts of the fleet:

Table 2. OCI service roles in the agent fleet infrastructure; workflow dependencies and refinement logic remain application responsibilities.

Above these services, Envoy, the MCP gateway, and the in-cluster message queue connect requests to agent execution. The fleet controller is an experimental CoE implementation built on OCI services, not a managed OCI agent orchestration offering. The math workflow record shows specialist handoffs, correction rounds, and review stages. Generalized dependency scheduling, durable checkpoint recovery, and global budget enforcement are design requirements discussed here, not capabilities validated by these artifacts. The biology analysis and matched-budget comparisons remain proposed work, not an OCI product roadmap.

Persistent files support continuity, but do not automatically resume a workflow. Recovery also requires the controller to restore task state and handle interrupted work. OCI documents that deleting a dynamically provisioned PVC can delete its backing file system; configure storage retention and test recovery explicitly.

4. Scientific workflow examples

4.1 Mathematics

We use a standard mathematical problem with a checkable result to explore how an agent fleet organizes research. The focus is the workflow: how specialists investigate different approaches, seek peer input, revise their work, and bring the findings together for verification and writing.

Figure 2 shows this collaboration as a swimlane, with one row per participating agent and one column per recorded phase. Read it from left to right to follow the work from Research and Peer work through correction, checking, and paper review. The connections between rows show handoffs, while the correction and revision stages show where feedback leads to another pass. This makes the dependencies and refinement loops visible within one research workflow.

Figure 2. The supplied math swimlane reports 69 completed tasks, 29 specialists plus a client agent, 13 autonomous peer handoffs, and two correction/convergence rounds. Phase widths are not measured durations; participating agents are not a concurrency measurement. Counts are reported from the workflow record, not independently audited execution logs.

The swimlane starts with ten research specialists investigating different approaches. Peer work brings in additional expertise when a branch needs help. The Correction and Recheck columns show where findings are revised and checked before Agreement and Content check. Paper v1 then moves through Export check, Paper review, Paper v2, and Final review. In the legend, blue marks research and writing, amber marks correction and revision, green marks agreement, verification, and approval, and purple marks client coordination.

Table 3. How the mathematics workflow combines dependencies with refinement.

Verification is a separate stage from agent agreement. The swimlane names checker and reviewer roles, but does not show their code or output. Substantiating the reported result requires the underlying artifacts, construction code, configuration, and independently checkable certificates. The workflow lesson is to define an executable acceptance check before investigation begins and preserve its evidence before moving to paper writing. The example does not establish scientific novelty or a performance advantage.

Here, the graph connects specialist work and verification stages; loops return problems to the relevant branch before the workflow proceeds. A next step is to compare this approach with a single agent and conventional methods under the same resource budget, measuring verified completion, time, and cost. The recorded handoffs show how collaboration is organized, but do not by themselves establish an efficiency gain.

4.2 Physics knowledge review and synthesis

We use a physics knowledge-review example to explore how specialist contributions can be combined into a coherent report. The workflow challenge is to divide a broad subject into manageable topics, connect the findings, and review the combined explanation for consistency and supporting evidence. The example concerns established knowledge, not a new physics result.

Figure 3 presents an adapted title-page excerpt with ten illustrative agent roles. The separate paper, From Quanta to Quantum Fields, provides an example of the written output. Its title page illustrates topic coverage, not the sequence of execution; the workflow below is an architectural interpretation, not a reconstructed trace of how the paper was produced.

Figure 3. Adapted excerpt from the physics knowledge-synthesis paper. Demo-agent names are replaced with neutral illustrative roles; these labels are not a reconstruction of task assignments. Historical attribution within the abstract is retained.

In this pattern, topic reviews form independent branches in the dependency graph. Each branch supplies a summary and supporting references to a synthesis task, which waits for the required contributions. A reviewer then checks the combined report for gaps, inconsistent explanations, and unsupported claims. Feedback returns to the responsible branch, and the synthesis is refreshed after revision.

The paper marks several sources still needed, illustrating why this review loop matters. A missing reference creates a concrete follow-up task: find supporting evidence, narrow the claim, or remove it. Here, the graph organizes contributions, while the loop improves the combined explanation. Acceptance should depend on source checks and qualified review, not agent agreement alone.

4.3 Biology exploration around an open question

We use an exploratory biology question to consider a workflow that combines data analysis with literature review. The focus is how agents could prepare shared inputs, investigate different aspects of a question, and bring evidence together for interpretation. The recorded work reached input-access validation only. The following workflow is proposed; no completed biology analysis or biological result is reported here.

Table 4 shows the dependencies and feedback paths. Analysis waits for validated data, while literature review can proceed from the defined question. Both branches feed synthesis. If review identifies a data problem, an unstable result, or an unsupported interpretation, the work returns to the relevant specialist.

Table 4. Proposed biology collaboration graph expressed as dependencies and return paths. Data and literature branches meet at synthesis.

In this design, agents would share a versioned input snapshot and save their outputs separately so reviewers can trace each finding to its source. Review loops would re-run analyses, test whether findings remain stable under reasonable changes, and check supporting references. Qualified domain review would assess the interpretation and preserve unresolved uncertainty or contradictory evidence.

Here, the graph coordinates work with different prerequisites, while loops test robustness and return findings for revision. Acceptance would require reproducible analysis and a supported interpretation. Completed trials and comparisons of outcome quality, time, and cost remain future work.

5. Conclusion

This exploration suggests a practical path for using agent fleets to assist scientific work. The examples are deliberately bounded: they help us examine collaboration and verification without implying a customer outcome or a scientific breakthrough. OCI provides the execution and persistent-workspace foundation for investigating that path. Graphs expose dependencies, loops act on feedback, and independent checks determine acceptance. Active concurrency should follow ready work and available budget rather than the size of the roster.

The math trace makes the collaboration mechanism visible: specialist handoffs, correction, content checking, and writing are separate stages with explicit return paths. The biology design extends the same approach to a workload where reproducibility and qualified interpretation replace a single finite certificate. Together with the earlier fleet demonstration, these examples support the feasibility of building research workflows on OCI. Their robustness in real business and research use still needs workload-specific testing, including interruption recovery, access controls, and repeatable outcome evaluation.

Start with one bounded question and a verifiable deliverable. Draw the specialist handoffs, define stopping rules, and compare against a capable single-agent baseline. On OKE, scale execution as ready work grows, retain versioned evidence in FSS-backed workspaces under an explicit retention policy, and keep acceptance decisions in the workflow controller. The next step is to validate workflow recovery and global budget controls, then measure outcome quality alongside time and cost. That is the progression from managing agents to engineering workflows.

6. References

This work is part of the JAPAC Center of Excellence (CoE) AI-First initiative. We aim to bring the latest advances in AI and infrastructure into practical business use cases across scientific research, industry, and other domains. Our approach is to explore promising technologies through focused experiments, understand their limits, and work toward applications whose value can be tested in real operating conditions.

The scientific workflows in this article were selected as illustrative use cases, not drawn from a customer deployment. The math swimlane is an experimental workflow record; the separate physics paper is a scientific-writing artifact; the biology case is a proposed extension. They explore how an agent fleet could facilitate research on OCI. Comparative efficiency, scientific novelty, and realized customer benefits are not claimed.

• Scaling 1,000 AI Agents on Oracle Cloud Infrastructure Kubernetes Engine and File Storage: the published infrastructure article and its request-test scope.
• Oracle Kubernetes Engine (OKE): container execution and cluster-level scaling.
• Oracle Cloud Infrastructure File Storage Service integration with OKE: persistent workspace volumes.