Agent Development Framework: Building Agents That Ground in Enterprise Reality

Core Principle

The semantic layer already exists in your customer's business. Your job is not to invent it. Your job is to extract it, formalize it, and make it machine-readable so agents can reason the way humans do.

The customer runs their business every day using implicit rules, policies, and decision logic. The CFO knows what revenue means. The controller knows what constitutes a valid payment. The supply chain manager knows which suppliers are trustworthy. This knowledge is embedded in their ERP, their processes, their policies, their memory.

Our job at lowtouch is to surface that knowledge, standardize it, encode it, and hand it to agents. Data does not move. Business logic gets made explicit.

A note on the examples in this document. The scenarios referenced throughout (finance and controller workflows, accounts payable, supply chain, help desk, and so on) are illustrative only. They are there to make the process concrete. The same three-phase approach applies to any domain and any process. Substitute your customer's actual use case wherever an example appears.

---

The Three-Phase Agent Development Process

Phase 1: Discovery and Extraction

Before you write any agent code, you extract the semantic layer from the customer's business.

Ask the right questions. How does the business currently make this decision? What data sources do they reference? What rules, thresholds, and exceptions apply? What policies constrain the action? What gets logged or audited? What would constitute a wrong answer, and how would you catch it?

Then collect the artifacts. Process documentation showing current state, not aspirational. Policy manuals and compliance guidelines. Decision trees or approval workflows, written or drawn. Data dictionaries and field definitions from their systems. Examples of correct decisions and incorrect ones. Exception cases and how they are handled. Regulatory and audit requirements.

The output of Phase 1 is a semantic model. It is structured and human-readable. It is documentation the customer recognizes and can validate. This is not code yet. This is the foundation.

Phase 2: Formalization and Encoding

You take that semantic model and encode it into machine-readable form. This is where the semantic layer becomes operational. There are six components to encode.

Data mappings. Which systems own which truth? Which table in which system is the source of record for customer data, financial data, product data? Map the physical schema to the business concepts that matter.

Business glossary. Define terms precisely. Not just "revenue," but "total invoiced amount for all active contracts in the calendar quarter, excluding test accounts, recognized when goods ship." Create synonyms and aliases so the agent understands that "top-line," "sales," and "ARR" are related but distinct concepts.

Calculated metrics. Formalize how key metrics are computed. COGS, gross margin, churn rate, customer lifetime value, cash position. Write these as formulas with embedded filters, joins, and business rules. Version control them. These are production logic, not ad hoc calculations.

Decision rules and thresholds. Encode the logic. If transaction amount exceeds X and customer risk tier is Y, escalate to approver Z. If inventory is slower than velocity threshold for ninety days, mark for markdown. If a supplier defaults, block new orders. These are the guardrails for the agent.

Access controls and data governance. Who can see what? Which agents can act on which data? Which transformations require approval? What audit trails are required? Encode this as RBAC and policy rules.

Relationships and ontologies. Map how business entities relate. Customer has contracts. Contracts have line items. Line items have cost codes and projects. Suppliers have categories and risk ratings. This is the knowledge graph. The agent uses it to reason across systems.

The output of Phase 2 is a semantic model that is machine-readable and agent-accessible. In the lowtouch architecture it is stored in two places, both version controlled. The structured logic, definitions, decision rules, thresholds, mappings, and access policies live in the agent YAML. The unstructured and retrievable knowledge, embeddings of glossaries, documents, and business context, lives in the vector database. Both run inside the lowtouch appliance and are accessible to agents at runtime. Because both are version controlled, every change is tracked, reviewable, and can be rolled back.

Phase 3: Validation and Governance

The semantic layer becomes both the agent's instruction set and the quality gate.

Validation looks like this. The agent retrieves semantic context before reasoning. The agent executes an action. The semantic layer validates the action against the same rules that guided it. Violations or exceptions are logged and escalated. The human reviews the exception, approves or rejects, and the feedback updates the semantic model if needed.

Governance looks like this. Every agent decision is traceable to the semantic rules it applied. Thought-logging shows which data the agent retrieved, which rules it referenced, and why it made the decision. Audit trails connect the agent's action to the human's validation or override. Changes to the semantic model go through version control and review before production. The customer's compliance team can audit the entire decision chain.

Conversational validation before go-live. The most direct way to confirm the agent understood the business is to let the stakeholders talk to it. Before the agent goes into production, the CFO, the controller, the domain owner, whoever owns the process, should be able to chat with the agent directly. They ask it questions. They pose real scenarios. They ask it to explain how it would handle a specific invoice, a specific exception, a specific edge case, and then they review the answers. If the agent explains a decision the way the expert would, the semantic layer is right. If it gets something wrong, that is a gap in the semantic layer, not a one-off error, and it points you straight to what needs fixing. This turns validation into a conversation the business owner can run themselves, in their own language, without reading YAML or queries. It is the fastest way to build trust and the fastest way to surface misunderstandings while they are still cheap to fix. Treat this conversational sign-off as a required acceptance gate, not an optional demo.

---

What to Keep in Mind During Development

1. Do not invent business logic. The customer's business logic already exists. Extract and formalize it. Do not improve it or second-guess it. If the CFO approves invoices with a certain threshold, that threshold goes into the semantic layer exactly as stated, even if you think it should be different. The agent's job is to execute the customer's logic consistently and at scale, not to optimize it. Optimization comes later, once the agent is in production and the customer has data on outcomes.

2. Talk to the right people. Extracting the semantic layer requires talking to domain experts, not just IT. For financial agents, talk to the controller and their team. For supply chain, talk to procurement and operations. For help desk, talk to the team leads. These people know the rules, the exceptions, the edge cases. IT can tell you the schema. The domain expert tells you the meaning.

3. Start narrow, not wide. Do not encode the entire semantic layer for the entire business in one sprint. Start with one domain, one process, one decision. Get it right. Build the agent for it. Validate it with the customer. Then expand. A semantic layer for accounts payable is different from accounts receivable aging. Start with one. Nail it. Move to the next. This lets you learn what works without betting the entire engagement.

4. Make the semantic layer visible and auditable. It should not be a black box inside the appliance. It should be readable, queryable, and understandable to the customer. They should see what rules an agent applied, what thresholds triggered an exception, what data the agent referenced. This is how you build trust. The customer reads the semantic layer and says, yes, that is how we work.

5. Version control everything. Changes to the semantic layer are changes to production logic. They require review, approval, and rollback capability. Track who changed what and when. Allow the customer to compare versions and roll back if a change breaks something. Treat the semantic layer like code, because for an agent, it is.

6. Plan for exception handling. Not every decision fits the rule. Encode what happens when the rule does not apply. Is the exception escalated? To whom? With what information? How does the human's decision feed back into the semantic layer? The agent handles routine decisions at scale. The human handles exceptions and improves the rules over time.

7. Connect to observability. Every agent action should be loggable and auditable. Log what semantic context the agent retrieved, what rules it evaluated, why it made the decision, what action it took, what the outcome was, and whether the decision was validated or overridden. This thought-logging is not just for compliance. It is how you debug and improve the agent. If an agent makes a wrong decision, you trace backwards and find which rule was wrong, which data was stale, or which logic was misapplied.

---

The Semantic Layer Checklist

Before you hand an agent to the customer, validate that the semantic layer is complete.

Data and glossary. Are all source systems mapped? Is there a business glossary for every key term? Are synonyms and aliases documented? Do all metrics have formal definitions with embedded filters and joins?

Decision rules. Are all thresholds encoded? Are all approval workflows mapped? Are all policy constraints captured? Are exception cases defined?

Access and governance. Is RBAC defined for who can see what data? Are audit requirements specified? Is the escalation path clear? Are compliance constraints encoded?

Validation and monitoring. Are quality checks defined for agent outputs? Is thought-logging configured? Is rollback capability in place? Is alerting set up for exceptions?

Stakeholder sign-off. Have the business owners chatted with the agent directly? Did they pose real scenarios and edge cases? Did the agent explain its decisions the way the domain expert would? Has the process owner signed off on the conversation as an acceptance gate?

---

What Success Looks Like

The agent executes the customer's decision logic consistently, at scale, with no human intervention for routine cases.

Exceptions are surfaced, escalated, and reviewed by humans with full visibility into why the exception occurred.

The customer understands exactly how the agent arrived at each decision, because the semantic layer is transparent and auditable.

Changes to business logic flow through the semantic layer and roll out to all agents without code changes.

Compliance audits pass because the entire decision chain is logged and traceable.

Over time, the semantic layer becomes the canonical source of truth for how the business operates. Not aspirational, not documented in a wiki. Executable and constantly validated.

---

Remember

The semantic layer is not software. It is the formalized representation of how your customer's business actually works. The agent is not intelligent. It is executing the rules you gave it. The value is not in the model. It is in making implicit knowledge explicit, so it can be scaled, audited, and improved over time.

Start there. Everything else follows.