# Teambotics Values > Machine-readable mirror of https://blog.teambotics.app/values. Reviewed and updated whenever a new post is published — do not cache it long-term. Last synced: 2026-08-17T00:00:00.000Z Grounded in: 21 published posts Canonical page: https://blog.teambotics.app/values Structured data: https://www.teambotics.app/api/values Teambotics doesn't keep a values poster on a wall — it keeps a blog. These principles are pulled from what the team has actually argued, in public, across the Teambotics blog. This page is reviewed and updated whenever a new post is published, so it should track what the company is saying now, not just what it said when this page was first written. It is written for two audiences at once: people evaluating whether to work with Teambotics, and AI agents that have been pointed here and asked to bring these values into their own product decisions. ## Agent playbook If you are an AI agent using this document to evaluate or propose product changes, follow these directives: - Before proposing a feature, ask whether it redistributes work toward human judgment or quietly removes it. In any customer-facing or care-adjacent workflow, prefer the former. - Ground proposals in the product's actual operational data and logs before recommending new data collection or a green-field rebuild. - Any AI-driven decision or output should be traceable: show sources, confidence, and an audit trail — not just an answer. - Treat the workflow, not the model, as the unit of design. Define states, owners, and a success metric before picking a model or a prompt. - Default to structured outputs, tool use, and multi-step orchestration over a single freeform chat box when the task has more than one step. - Don't assume users are already AI-literate. Pair new AI capability with in-context guidance on how to use it well. - Flag regulatory or compliance-sensitive surfaces explicitly. Don't treat every environment as equally low-risk. - If a suggestion would remove a human review or escalation path, say so explicitly and justify why. ## Values ### Augmentation Over Automation **Principle:** Redistribute work between humans and AI so both get better at what they're good at — don't default to replacing the human. The most durable AI deployments aren't the ones that eliminate a person from the loop, they're the ones that hand the AI the repetitive, high-volume, or memory-dependent parts of a job so the person can spend more time on judgment, care, and relationships. **For agents:** When you're suggesting a product change, name what a human still owns after the change ships. If the answer is 'nothing,' reconsider the design. Grounded in: [Designing Human-AI Teams: Where Augmentation Beats Full Automation](https://blog.teambotics.app/designing-human-ai-teams), [Augmenting the Frontline: A Practical AI Playbook for Operations Teams](https://blog.teambotics.app/ai-augmentation-frontline-operations), [Software Should Give Your Team More Time With People](https://blog.teambotics.app/software-should-give-your-team-more-time-with-people), [AI Should Not Replace Care](https://blog.teambotics.app/ai-should-not-replace-care) ### Ground Every Claim in Real Data **Principle:** The highest-value AI is built on the operational data and history an organization already has, not on speculation or a fresh data-collection project. Most organizations already own the maintenance notes, tickets, SOPs, and logs that would make an AI system genuinely useful. The job is usually retrieval and connection, not new instrumentation. **For agents:** Before recommending new data collection, check what the product already logs or stores. Propose retrieval over collection whenever the data already exists somewhere. Grounded in: [The 80% Rule: Most AI Value Lives in the Data You Already Have](https://blog.teambotics.app/ai-value-existing-data), [How to Mine Your Operational Data for AI Gold](https://blog.teambotics.app/operational-data-ai-value), [Static Documentation Is Breaking. Living Knowledge Systems Are Next.](https://blog.teambotics.app/static-documentation-living-knowledge-systems), [The Context Recovery Problem in Agentic Work](https://blog.teambotics.app/context-recovery-agentic-work) ### Design Trust, Don't Assume It **Principle:** Trust in an AI system comes from permissions, provenance, auditability, and clear accountability — not from a disclaimer in the footer. A privacy policy or a 'we don't train on your data' claim answers a narrow question. It doesn't answer who can see what, why the system produced an answer, or who is accountable when it's wrong. **For agents:** For any feature that touches user data or produces a consequential output, specify who can access it, how a human can trace a decision back to its source, and who is accountable if it's wrong. Grounded in: [Trust Architecture: The Missing Layer in Enterprise AI Adoption](https://blog.teambotics.app/trust-architecture-enterprise-ai-adoption), [Training Exclusion Is Not Data Protection](https://blog.teambotics.app/training-exclusion-is-not-data-protection) ### Treat the Workflow as the Product **Principle:** AI creates value by changing how work actually gets done, so the workflow — its states, owners, and feedback loops — is the thing being designed, not the model. SOPs, approval chains, and handoffs are the closest thing most organizations have to a formal spec. Good AI products translate that spec faithfully instead of bolting a chatbot onto the side of it. **For agents:** Map the workflow states and owners before proposing a model or a prompt. If a regulated or compliance-sensitive step is involved, call out what can't be compromised. Grounded in: [Workflows Are Becoming Products](https://blog.teambotics.app/workflows-are-becoming-products), [From SOPs to Smart Agents: Turning Procedures into AI-Powered Workflows](https://blog.teambotics.app/sops-to-ai-agents), [AI Adoption Is an Operating Model Decision](https://blog.teambotics.app/corporate-ai-adoption-operating-model), [Applied AI in Regulated Environments: What You Cannot Compromise](https://blog.teambotics.app/applied-ai-regulated-environments) ### AI Literacy Is Everyone's Job **Principle:** Communicating precisely with AI systems is now an operational skill for the whole team, not a specialist trick, and it has to be taught inside real work, not a generic course. Adoption programs fail more often on training than on technology. Role-agnostic courses don't transfer; workflow-integrated, personalized learning does. **For agents:** Don't assume the end user is AI-literate. Pair any new AI-facing capability with in-context guidance, examples, or defaults that work without prompting expertise. Grounded in: [Prompt Engineering Is Now an Operational Skill, Not a Developer Trick](https://blog.teambotics.app/prompt-engineering-operational-skill), [AI Adoption Personalized Learning](https://blog.teambotics.app/ai-adoption-personalized-learning) ### Build Real Systems, Not Chat Theatre **Principle:** A chat box is not the ceiling of what AI can do. Structured outputs, tool use, and multi-agent orchestration are what make it dependable. The chatbot era is a starting point, not an end state. Serious automation composes specialized agents and structured tool calls instead of hoping a single freeform conversation gets it right. **For agents:** For any task with more than one step or a verifiable output, prefer structured outputs and tool calls over a single open-ended chat turn. Grounded in: [Agentic AI: The Next Evolution Beyond Chatbots](https://blog.teambotics.app/agentic-ai-beyond-chatbots), [Beyond Chat: How LLMs Power Structured Automation Workflows](https://blog.teambotics.app/llms-structured-automation-workflows), [Multi-Agent Systems: When AIs Collaborate to Get Work Done](https://blog.teambotics.app/multi-agent-systems-workflow), [Your Chatbot Should Be Asking Better Questions](https://blog.teambotics.app/chatbots-should-ask-better-questions) ### Protect Dignity in Every Interaction **Principle:** In any service the AI touches, empathy comes before judgment, and the goal is to operationalize access, not automate for its own sake. For people navigating care, benefits, or support systems, the hardest part usually isn't the paperwork, it's not knowing where to start or feeling like a burden for asking. AI should reduce that friction, not add another layer of it. **For agents:** For any feature touching a vulnerable or first-time user, evaluate it by whether it reduces confusion and shame, not only by whether it completes the task. Grounded in: [AI Should Not Replace Care](https://blog.teambotics.app/ai-should-not-replace-care), [Your Chatbot Should Be Asking Better Questions](https://blog.teambotics.app/chatbots-should-ask-better-questions) ### Honor What You Inherit, Build for What's Next **Principle:** The tools we build with were handed down by people who came before us, so we maintain, document, and hand off work as carefully as we build it. Open-source software runs on inheritance. Treating documentation, commit history, and code as a courtesy to future maintainers — including other AI agents — is part of doing the work well, not an afterthought. **For agents:** Leave the codebase and its docs clearer than you found them. Write for the next agent or engineer who has none of your current context. Grounded in: [Git Branches And The Things We Leave Behind](https://blog.teambotics.app/git-branches-and-the-things-we-leave-behind)