Ethgent: Fitting an Agent to a System by Separating Agent, Connection and Workflow Factory

Author abstract

Abstract

A company that wants a language-model agent to work for it has to put that agent inside its own backend service, join it to the application and the outside world, and shape its orchestration to the company’s own work. This paper is about that relationship between the agent, the backend service and the system around it. A model becomes useful there only when it is fitted: given the right instructions and tools, a way to read what happens, a way to act on it, and limits on what it may do. Fitting should not mean building a new agent for every company or domain. We describe a small set of open-source components that separate these concerns instead of fusing them in one process: a customisable agent whose agents and tools are configuration (Ethgent), a connection layer and open pool of workers, connectors and contracts (Marketing Agent Assets), a workflow factory that turns capabilities into deterministic, exportable tools (MarketingStudio), and a worked example that runs the combination on one machine (MarketingPool). Our working domain is marketing, but the design is domain-neutral: what changes between domains is the instructions, the tools and the connections, and we say precisely which parts those are. We built no second domain, so that is an argument from the design, not a result. The aim is an open contribution system: through GitHub and a common export format, different people can add an agent, a tool, a skill or a worker, and an organisation can assemble them into an extension that runs inside its own system. Credentials stay with workers; anything that changes the outside world is approved by the host, not by the model; every component works without the others and they meet through plain files and small contracts. We report what we ran: a workflow written in the factory, exported, installed and called by an agent backed by a hosted model, including one that needs approval, one that takes a file and one that needs a package, two design faults that this exercise exposed and fixed, and a measured comparison (a three-step task and an eight-step chain, two models of one vendor, 15 to 20 runs per cell): giving the agent a workflow as one tool instead of the same steps as separate tools cut tokens by 10 to 40 percent on three steps and by a factor of about two on eight, with no statistically detectable difference in reliability. We also ran the agent as a worker inside the backend service of a real application of ours: the application’s contract checker passed (19 of 19), the agent saw only the lessons the application approves, and a database role limited it to its own queue. We do not report an end-to-end deployment against real platforms, and we say where the evidence ends.

Research question

How does a company put an agent inside its own backend?

A company that wants an agent to work for it has to place it inside its own backend service, join it to its application and the outside world, and shape its orchestration to its own work. Agent systems usually fuse prompts, model credentials, platform keys and business logic into one process, so each new company or domain means a new agent. Ethgent asks which parts of an agent are fixed and which are fitted, and whether keeping them apart lets people contribute agents, tools, skills and workers that an organisation can assemble inside its own system, without the model ever holding the keys or approving its own side effects.

Results

Key findings

System design

Four parts, each usable on its own

Ethgent

An orchestrator that delegates to sub-agents, each owning its tools; agents, tools and prompts are configuration that travels as installable packs

Marketing Agent Assets

The connection layer and open pool of workers, connectors and contracts; workers hold the credentials and validate requests against schemas

MarketingStudio

A workflow factory that turns capabilities into deterministic tools exported as agent bundles or MCP servers

MarketingPool

A worked example that runs agent, pool and workers together on one machine with Docker

Trust boundary

The agent writes requests to a queue; side effects are approved at call time by the host, never by the model

Evaluation

Workflow-as-tool versus separate tools on three- and eight-step tasks, two models of one vendor, 15 to 20 runs per cell

Open research

Code and paper

Scope

Limitations

• No real platform was touched; publishing and platform data were not exercised end to end.
• The comparison is small: one vendor, two models, short chains and 15 to 20 runs per cell.
• Approval is per tool, so approving an exported workflow approves all of its steps.
• The contribution system is a mechanism, not yet a community; there is no registry or review of contributions.
• No company outside the authors has adapted it; every backend run used an application and configuration of our own.
• The asset and platform-data sub-agents are built-in code in one copy of the agent and have not been reused outside the project.
• Other domains, such as trading or human resources, are consistent with the design but were not built.

Reuse and citation

Cite this preprint

Öztürk, A. R., Dalar, Y. E., Aksoy, Ö. F., Sezer, N. M., & Salihoğlu, F. A. (2026). Ethgent: Fitting an Agent to a System by Separating Agent, Connection and Workflow Factory. Ethosoft preprint. https://ethosoft.org/papers/Ethgent/

Download the BibTeX citation

@techreport{ozturk2026ethgent,
  title       = {Ethgent: Fitting an Agent to a System by Separating
                 Agent, Connection and Workflow Factory},
  author      = {Öztürk, Ahmet Rıfat and Dalar, Yağız Ekrem and
                 Aksoy, Ömer Faruk and Sezer, Nedim Mutlu and
                 Salihoğlu, Feyzi Arda},
  institution = {Ethosoft},
  type        = {Preprint},
  year        = {2026},
  month       = {October},
  url         = {https://ethosoft.org/papers/Ethgent/},
  note        = {Not peer reviewed. CC BY 4.0}
}