What Teambotics actually believes
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.
Augmentation Over Automation
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.
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.
Ground Every Claim in Real Data
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.
Before recommending new data collection, check what the product already logs or stores. Propose retrieval over collection whenever the data already exists somewhere.
Design Trust, Don't Assume It
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 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.
Treat the Workflow as the Product
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.
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.
AI Literacy Is Everyone's Job
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.
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.
Build Real Systems, Not Chat Theatre
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 any task with more than one step or a verifiable output, prefer structured outputs and tool calls over a single open-ended chat turn.
Protect Dignity in Every Interaction
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 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.
Honor What You Inherit, Build for What's Next
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.
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.
Agent playbook
Concrete directives for an AI agent applying these values when it proposes product or feature changes.
- 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.