AN ENGINEERING FIELD NOTE · OCTOBER 2026 · WORK IN PROGRESS
An engineering work-in-progress note
This note documents an early development and experimentation phase of Grove v0.1. The implementation and experiments described here were conducted in a contained, local development environment, using Ollama and locally hosted models Gemma 4:31B Dense model on an Apple Mac (M3 Max).
The architecture, model configurations, runtime parameters, agent workflows and performance observations represent the state of experimentation at the time of writing. They are not production benchmarks, final specifications or commitments to a particular implementation.
Grove is actively evolving. These configurations, architectural decisions and experimental observations may change as development progresses, further testing is conducted, and additional models and capabilities are introduced. The purpose of publishing this note is to share the engineering process transparently, including the decisions, observations, limitations and unresolved questions.
Most importantly the journey, evolution and learning
1. The Agent Harness as a First Principle
1.1.What Is an Agent Harness?
A language model can understand instructions, reason through problems and generate responses. But building a useful AI agent requires more than connecting an application to a model. The agent also needs a way to manage its context, use tools, execute tasks, handle errors and decide what to do next.
This surrounding system is called the agent harness.
In simple terms, think of the model as the engine and the harness as the machinery that allows the engine to do useful work. The model provides the intelligence; the harness provides the structure, controls and environment in which that intelligence operates.
A useful way to express this relationship is:
Agent = Model + Harness
1.2. DeepSeek Harness: A Case Study in Composable Design
An interesting example of this approach is DeepSeek Harness (dsh). Rather than building an agent around one large, tightly coupled core, it follows an everything-is-a-plugin design. Capabilities are organised into independently mounted components, each responsible for a specific part of the agent’s operation. We felt this more useful for our harness building internally majorly for two advantages off-the-shelf using DeepSeek:
Harness as a pluggable model, helps for using multiple open and closed models for different usecases: Research, documentation, coding etc.
TypeScript SDK support for orchestration
Some of its key architectural ideas include:
Session management: Maintains an event log of the interaction and derives the conversation history that is presented to the model.
System prompt assembly: Brings together tool descriptions and prompt sections to construct the model’s working instructions.
Tool execution: Provides a scoped tool registry and a guarded execution pipeline.
Agent and execution loop: Defines how agents are registered and how their execution is driven.
Capability seams: Creates boundaries that allow underlying providers to be replaced without having to redesign the capabilities that depend on them.
The important idea is not simply that the system supports plugins. It is that the harness itself is designed to be modular, replaceable and extensible.
1.3. How Grove Interprets This
Grove follows the same broader principle: the harness should not be an incidental layer hidden inside an agent implementation. It should be an independent, first-class part of the architecture.
Our interpretation is that agents should define what work needs to be done, models should provide the intelligence, and the harness should govern how that work is carried out.
This separation allows Grove to introduce new agents and experiment with different models without having to rebuild the underlying runtime each time. The harness provides the common execution foundation, while individual agents bring their own capabilities, workflows and domain-specific instructions.
For Grove, this is both an architectural principle and an ongoing engineering direction. The objective is to build a foundation where models and agents can evolve independently, while the harness provides consistency, control and extensibility across the system.
A useful working formulation for understanding modern AI agents is:
Agent = Model + Harness
In this framework, the language model provides the underlying intelligence, while the harness serves as the runtime that converts that intelligence into actual work.
The harness constitutes the infrastructure that couples an LLM to the world through a loop, tools, orchestration, safety controls, context management, and extension surfaces. Specifically, the harness is critical because it mediates trajectory control, action execution, tool use, observation, and the interpretation of feedback.
Grove adopts the philosophy by treating its harness as both a first principle—the governing rules every agent run must obey regardless of the model’s behaviour—and a first-class citizen.
This is reflected in the implementation: Grove maintains the harness as its own distinct component within @grove/runtime, where it manages the run lifecycle, deadlines, cancellation, error policies, and provides a recorder with redaction for observability.
The distinction matters. The model should be replaceable without fundamentally changing the runtime that governs how an agent operates.
2. Pluggable and Composable Architecture: The DeepSeek Harness Case Study
Research into dynamic composition indicates that modern software, including evolving agent harnesses, increasingly requires composability.
A primary example is the DeepSeek Harness (dsh), which employs an “everything-is-a-plugin” design.
DeepSeek Harness architecture
The dsh avoids a privileged core; instead, it is extended by mounting plugins that can be unwound upon unloading.
Its architecture is segmented into packages owning specific context keys:
core/session: Owns thectx.sessionsappend-onlySessionEventlog.core/system-prompt: Manages tool-schema and prompt-section assembly (ctx.systemPrompt).core/tools: Handles the guarded execution pipeline and scoped tool registry (ctx.tools).core/agentandcore/agent-loop: Define theAgentinterface, live registry, and default driver (ctx.agents,ctx.agentLoop).
Further architectural details are available in the DeepSeek Harness architecture documentation and its core subsystem documentation.
Key technical features of dsh
Session log
The session log is the primary source for model context. It uses deriveMessages() to project history; notably, it retains failed, cancelled, or retried attempts in assistant/attempt without adding them to the model’s history.
Reference: DeepSeek Harness – Session subsystem.
Capability seams
dsh utilises “seams” that allow for provider swaps without requiring provider forks. For example, shifting filesystem and subprocess providers to a remote sandbox moves Bash, LSP, and PTY collectively.
Comparison with Grove
While the available evidence does not detail every architectural component of Grove’s harness, it shows that Grove similarly implements pluggable agents via an AgentDefinition contract in @grove/sdk, ensuring that registering a new agent does not change the runtime.
Like dsh, Grove separates the runtime from the agent implementations.
The comparison here is architectural, rather than a claim that both systems have identical implementations.
3. Current Implementation: Grove Local Testing
Grove’s harness is currently being hosted and tested on a local Mac using Ollama.
For testing purposes, a Gemma 4 31B dense model has been run locally using the
gemma4:31bmodel identifier.Additionally, smoke tests have been conducted on an Apple M3 Max (CPU only) using
qwen2.5:3bvia Docker Desktop.
The local-inference infrastructure and its configurations are documented in the Grove local-inference README.
These are development and experimentation environments, not production deployment configurations.
4. Initial Release Model Strategy
The initial release involves consideration of the following models:
Gemma (latest version)
LLama Muse
Qwen 3.8
GLM 5.3
Kimi 3.1
The intention is to use a model router to manage these multiple models. The design of this router or the planned implementation is using Mixture of Experts (MoE).
5. Roadmap: Agentic Pipeline Evolution
Grove’s agentic pipeline is intended to evolve in the following order.
5.1 Research Agent
Intended for evidence-grounded research, literature reviews, and white papers.
It utilises a staged pipeline with human review gates and specific roles for extraction, drafting, and verification.
The current Research Agent implementation can be explored in the Grove Research Agent source.
5.2 Documentation Agent
Aimed at documentation drafting and maintenance.
This agent is described in the project’s documentation but has not yet been registered or built in v0.1.
5.3 Coding Agent
Designed as a repository-aware engineering assistant for Nx consolidation.
Its goal is to move from a polyrepo to a modular monolith with an application layer encompassing the backend, frontend (with future mobile/desktop apps), and shared libraries.
It will utilise a “read-only analysis first” approach followed by gated patch proposals in a sandbox.
These three agents represent the intended evolution of Grove’s agentic pipeline, not a claim that all three are already implemented.
6. Interface and Distribution
Grove v0.1’s interface is interpreted to consist of a CLI, which serves as the composition root to wire the system together.
The technology stack for the harness and SDK is TypeScript.
Grove is a potential open-source release under the name Parjanya by Phagyul AI Systems Pvt Ltd.
The interface and distribution strategy remain subject to further development.
7. Experimental Record: Gemma 4 31B on Local Ollama
This section documents the experimental configuration and observations from running Grove’s research agent locally.
The run was hosted and tried on an Apple Mac M3 Max using Ollama running gemma4:31b.
The following records cover token consumption, observed performance, research-agent limits, sampling parameters, engine-level settings, and related environment configuration.
7.1 Token Usage and Performance
Individual model calls
The process involved varying input and output token counts across different sequences.
These are selected individual model-call observations from the experimental run.
Total usage
Across 38 model calls, the total token usage for writing the first post draft was:
Performance records
The recorded performance observations were:
Prompt evaluation speed: Ranged from approximately 79.60 tokens per second (seq 1531) to 118.39 tokens per second (seq 0).
Generation speed: Ranged between 8.49 tokens per second (seq 946) and 13.61 tokens per second (seq 925).
These figures are observations from the recorded run and should not be interpreted as controlled or generalised model benchmarks.
7.2 Research Agent Limits and Thresholds
The following limits and thresholds were used for the research agent.
The timeout and retry values are defined in the Gemma expert configuration. The context budget is defined in the research-agent harness configuration, and the default deadline is defined in the Research Agent implementation.
Relevant implementation reference: Grove Research Agent.
7.3 Ollama Sampling Parameters
The sampling settings recorded for the gemma4:31b model were as follows:
Both observations are retained here rather than choosing one value without further verification.
For parameter definitions and their behaviour, refer to the official Ollama Modelfile documentation.
7.4 Model Engine and Environment Settings
llama-server parameters
The following engine-level parameters were recorded when Ollama started the llama-server for this run.
These are the recorded llama-server settings from the model-load log.
Related Ollama environment configuration
The following values are present in Grove’s Docker Compose configuration for local inference:
Important distinction: These values are documented in Grove’s Docker Compose configuration. The Gemma experiment described above used the Ollama application on the Mac, not the Docker Compose Ollama service. Therefore, these environment variables should not be interpreted as confirmed settings for that specific experiment.
Configuration reference: Grove local-inference Docker Compose.
For additional context on Ollama environment variables and context-window configuration, refer to the official Ollama FAQ.
7.5 Conflicts and Uncertainties in the Experimental Configuration
There are two configuration discrepancies worth documenting.
1. Conflict in top_p
There is a conflict between the llama-server load log, which specifies top_p as 1.0, and the Ollama model parameters, which list it as 0.95.
2. Uncertainty in context length
It is unclear which setting took precedence during the run:
The llama-server was started with a context size of 32,768 tokens.
The
OLLAMA_CONTEXT_LENGTHenvironment variable in the related Docker configuration was set to 16,384.
Since the Docker configuration was not used for the documented Mac experiment, the latter value does not establish the effective context length for that run.
The sources do not specify any other limits or parameters beyond those listed above.
8. Evolving Grove: Areas of Continued Development
Grove v0.1 is an initial foundation, not a finished system. As the architecture evolves and additional models are integrated, several areas will receive further attention, experimentation and refinement.
Some of the areas we intend to explore include:
Multi-model intelligence and routing: Expanding model support and developing the model router, including the exploration of a Mixture of Experts (MoE) approach to direct tasks to suitable models based on their capabilities.
Multimodal research capabilities: Further developing image-processing workflows, including handling high-bit-depth RAW files, image analysis and more effective filtering and evidence extraction.
Documentation automation: Extending the Documentation Agent to support practical engineering and publishing workflows, including blog posts, READMEs, technical documentation and white papers, with integration into the relevant model services.
Interfaces and accessibility: Exploring interfaces beyond the initial CLI as Grove’s runtime and agent capabilities mature.
Performance and model evaluation: Comparing models across different hardware and execution environments, with a focus on inference speed, token consumption, reliability and task quality.
These are evolving areas of engineering work rather than fixed specifications. Their implementation and priorities will be shaped by experimentation, practical usage and feedback as Grove develops.
For a more detailed view of ongoing work, planned enhancements and implementation priorities, refer to the Parjanya Engineering Issues and Roadmap.
For shipped improvements and version-specific changes, follow the Parjanya Release Notes.
9. References and Evidence
The following public references provide context for the architecture, implementation and experimental configuration.
Architecture and agent harness
Grove implementation
Model and runtime documentation
Internal experimental evidence
The experimental figures in this note are based on the local run records, Ollama model-load logs, request logs, Grove configuration and run records captured during the experiment.
These are internal development artifacts and are not publicly accessible through the links above. The original evidence export records the associated source files, line ranges, quoted passages and file fingerprints.
The local logs and configuration snapshots are retained as the supporting engineering record.
Grove v0.1 is a work in progress. This note captures an early point in its development, not a final destination. The architecture will evolve, the models may change, and the experimental parameters will be revisited as the system matures. We are sharing the process as it happens, including what works, what remains uncertain, and what we learn along the way.
