Problem:
Manual ops and scattered documents do not scale, and generic chat tools do not know the business. A team pastes the same context into a consumer assistant every morning, or they point a vendor bot at a drive and hope retrieval does the thinking. Neither is a system. Both leak, stall, or confidently answer from the wrong file.
The hard part is rarely the model. It is deciding which documents an agent may see, how those documents are chunked and retrieved, what the loop is allowed to do next, and where a person still has to approve a step. Without those contracts you get a demo that looks fluent and a production path you cannot audit.
We have already learned some of this the expensive way. Hermae retrieved against design-system source and generated an assistant on top. Deco Agent Network put capabilities behind plugin manifests instead of one mega-prompt. The useful residue is not a brand name. It is the habit of making context and tools explicit.
Approach:
Carbonology builds custom agents, context, and loops for a particular business: which documents to expose, how they are retrieved, and where a person still approves a step. We start from the job, not from a model card. What question is being asked, what source of truth would make the answer safe, and what action — if any — the agent should take.
Context engineering here means more than a bigger prompt. It means a corpus you can update, retrieval you can inspect, and instructions that name the limits. Agent loops mean a sequence with state: gather, propose, wait, act. Some loops never act. They draft, and a person sends. That is often the correct product.
We will tell you when a spreadsheet and a saved prompt are enough. Building an agent because the category is loud is how you get a system nobody trusts. If the job is real, we design the smallest loop that would change the week, then we implement it so the team can see what it used. Contact us with the workflow, not with a model preference.
Deliverables:
- A workflow map: the human job, the sources of truth, the allowed actions, and the approval points.
- A document and retrieval design — what is in, what is out, and how updates land without silent drift.
- An agent or assistant implementation with inspectable context, not a black box wrapper on a vendor chat UI.
- Tooling and plugin boundaries when the agent must call into other systems, following the same contract habit we used on Deco.
- Evaluation notes: what “good” looks like for this loop, and a short set of cases you can re-run after a change.
- Handoff so an internal owner can operate the corpus and the loop without us in the middle of every edit.
Who it's for:
Operators who have a repeating knowledge or coordination job — support, internal research, document Q&A, structured drafting — and who already know which files would make an assistant useful. Product teams who need an agent inside their own software, not a chatbot taped to the homepage.
If you only want a ChatGPT wrapper with your logo, that is not this service. If you want a loop that knows your documents and stays inside the rails you set, that is.
Related:
Questions:
Almost never as the first move. Most useful systems are retrieval, tools, and a tight loop on a hosted model. Fine-tuning shows up only when the job has a stable format the base model cannot hold.
Either. Many first versions should only answer or draft. Actions — creating a record, sending a message, opening a ticket — need an explicit tool and an approval rule. We will not hide a write behind a chat bubble.
Whatever you have the right to use and the stomach to retrieve: policies, product docs, selected mail, structured exports. Secrets and anything that must not leave a vault stay out. Part of the work is saying no to the corpus.
Describe the job in a paragraph, name the systems of record, and say whether a person must approve the last step. Send that through Contact. We will tell you if a custom loop is warranted.