Digital Transformation | Giulia Solinas

Building Agents in Bob with a Software Spec Driven Approach

Fri, 03 Jul 2026 00:00:00 +0000

Building Agents in Bob with a Software Spec Driven Approach

Agentic systems become easier to build, review, and evolve when they are treated like software products instead of clever prompts. Bob’s dedicated skills support exactly that style of work: start with business intent, turn it into explicit specifications, generate implementation artifacts, and then analyze the result against the design.

In this post, I describe how to use Bob and four dedicated skills as an end-to-end, spec driven workflow for creating watsonx Orchestrate (wxO) agentic solutions.

Why Spec Driven Agent Development Matters

Traditional agent building often starts with a prompt and quickly jumps into tools, flows, and integrations. That can work for experiments, but it becomes fragile when the solution has real business logic, compliance expectations, system integrations, or multiple collaborators.

A software spec driven approach flips the sequence:

Define the business problem before choosing the implementation.
Produce architecture and process specifications before generating code.
Keep business rules legible in Standard Operating Procedures (SOPs).
Generate wxO artifacts from the agreed specification.
Analyze the implementation and feed findings back into the next iteration.

In this framework, the specification is not a bulk of documentation that none reads and gets under the deck of work to be done for a client. It is the contract that the developer signs with the agent.

The Bob Skill Pipeline

We can bring into the Bob’s workspace (global or at the project level) four specialized skills that form a complete pipeline for designing, building, and auditing wxO agentic solutions:

Skill	Primary Question	Output
`solution-architect`	What should we build, and why?	Solution overview, architecture, and implementation plan
`sop-builder`	How should the business process work?	Structured SOP with process flow, data needs, rules, and decisions
`wxo-builder`	How do we turn the spec into wxO artifacts?	Importable wxO project with agents, tools, flows, connections, and scripts
`wxo-analyzer`	Does the implementation match expectations?	Documentation and audit reports for an existing wxO project

The skills are avaialble in the GitHub repository for . We can clone the repo and import the folders into our project.

The important pattern is that each skill produces the input for the next one. That makes the workflow traceable from business problem to deployed solution.

Step 1: Start with `solution-architect`

Use solution-architect when you have a business problem or use case, but no technical design yet.

Example prompt:

I need an AI agent that processes invoices from a shared mailbox, extracts invoice data, validates it against vendor records, and prepares a SalesForce update.

The goal at this stage is not to write code. The goal is to create a shared understanding of the solution.

The agent using the solution-architect skills should produce three key documents:

Document	Purpose
Solution Overview	Captures the executive summary, business context, problem statement, and agent requirements
Solution Architecture	Describes components, integrations, data flow, security, and architecture diagrams
Implementation Plan	Breaks the work into phases, assumptions, constraints, and SOP candidates

The implementation plan is especially important because it decomposes the solution into business processes that can be specified independently.

Step 2: Convert Architecture into SOPs with `sop-builder` skills

Use sop-builder skills when you have an architecture document, workflow description, BPMN model, Langflow export, n8n export, or any other process-oriented input.

This skill turns design intent into a plain-language Standard Operating Procedure. That SOP becomes the specification for implementation.

A good SOP includes:

Business process flow diagrams
Business context and problem statement
Input, processing, and output data requirements
Business rules and decision points
Integration expectations
Error handling and escalation behavior

This is where the spec driven approach becomes practical. Instead of embedding business logic directly in generated tools or agent instructions, you first make that logic visible and reviewable.

Example prompt:

Build the SOP for the invoice extraction and validation flow from the implementation plan.

For larger solutions, a good option can be creating one SOP per major flow. A single monolithic SOP usually hides important decisions and makes generation harder to review.

Step 3: Generate the wxO Solution with `wxo-builder` skills

Use Bob with wxo-builder skills when you have an SOP or a very clear build prompt and want actual watsonx Orchestrate artifacts.

This is the point where Bob moves from specification into implementation. Given a strong SOP, wxo-builder can generate an importable wxO project structure such as:

my_solution/
 agents/
 my_agent.yaml
 tools/
 my_tool.py
 my_flow.py
 connections/
 my_connection.yaml
 main_flow.py
 import-all.sh

The agent with the builder skills can create:

Native wxO agents
Python tools with correct decorator and docstring conventions
Flow Builder patterns for document processing, user activity, conditional logic, and multi-agent workflows
Knowledge base configurations
Connection YAML files for credential management
Import scripts for repeatable setup

The quality of the generated solution depends heavily on the quality of the SOP. If the SOP defines the business rules, data contracts, exception paths, and integration behavior, the builder has fewer assumptions to invent.

Example prompt:

Generate the wxO solution from this SOP. Create the agent configuration, required Python tools, connection specs, and import script.

This step should usually happen in Agent mode because it writes project files. Note that you can further empower the agent mode by giving MCP connections to the Orchestrate documentation through the wx orchestrate ADK. However, a downside of MCP connections is larger token consumptions. An alternative method would be using the CLI skills approach by Floring Manila and Niklas Heidoff as explained in this .

Step 4: Audit and Document with `wxo-analyzer` skills

Use wxo-analyzerskills when you have an existing wxO project and want to understand, document, or audit it.

The Agent with the analyzer skills should produce a three-report documentation set:

Report	Purpose
Solution Overview	Summarizes architecture, components, and file structure
Agent Analysis	Breaks down each agent, its tools, collaborators, instructions, and LLM settings
Tools and Components	Reviews flows, Python tools, connections, knowledge bases, and implementation patterns

This closes the loop. After generating or modifying a solution, analyze it and compare the reports against the original architecture and SOPs.

Useful review questions include:

Does the generated agent follow the intended process?
Are business rules represented explicitly?
Are credentials handled through connections instead of hardcoded values?
Are error paths and escalation paths implemented?
Are tools too large, too ambiguous, or missing validation?
Does the implementation introduce behavior that was not in the SOP?

The output of the step obtained with wxo-analyzer skills can feed back into the tasks for the sop-builder or wxo-builder for refinement.

A Practical End-to-End Flow

Here is the full workflow in one sequence:

Business problem
 -> solution-architect
 -> Solution overview, architecture, implementation plan
 -> sop-builder
 -> Standard Operating Procedure
 -> wxo-builder
 -> Importable wxO project
 -> wxo-analyzer
 -> Audit reports and improvement backlog

Best Practices for Spec Driven Agent Work

Start with architecture for non-trivial use cases. If the solution touches multiple systems, users, approval steps, or data sources, begin with solution-architect skills.

Keep SOPs focused. One SOP per flow makes the specification easier to review and easier for wxo-builder skills to implement cleanly.

Treat the SOP as the contract. The SOP should define data inputs, outputs, business rules, decisions, and exceptions clearly enough that implementation choices can be checked against it.

Build from reviewed specs. Do not rush from a vague idea to generated code. The fastest path is usually to clarify the spec first.

Analyze after building. Call the agent with the wxo-analyzer skills after generation or major changes so the project can be reviewed for missing error handling, hardcoded credentials, oversized flows, or behavior that drifted from the SOP.

Iterate deliberately. When the agent finds gaps, update the SOP or architecture first when the gap is conceptual. Update the wxO implementation when the spec is right but the build needs refinement.

What This Changes

Bob’s dedicated skills make agent development like professional software delivery.

The workflow creates a chain of accountability:

Business requirements explain why the agent exists.
Architecture explains how the solution should fit together.
SOPs explain how the work should happen.
wxO artifacts implement the agreed process.
Analyzer reports show what was actually built.

That chain is what makes agentic systems deliverable and maintainable. It gives teams a way to discuss requirements, review logic, generate implementation, and audit the result without losing the thread between business intent and technical behavior.

When used together, solution-architect, sop-builder, wxo-builder, and wxo-analyzer skills turn Bob into a spec driven agent factory: one that can move from idea to implementation while keeping the reasoning visible at every step.

AI for Science

Tue, 21 Jan 2025 00:00:00 +0000

AI‑Enhanced Science: How Generative Models Are Accelerating Discovery, Literature Mining, and Idea Generation
Originally featured on the 

1. AI as a “Hilbert” for Equation Discovery

The most eye‑catching advance comes from the AI‑Hilbert algorithm, whose recent Nature Communications paper demonstrates that multivariate polynomial generators can invent new scientific laws from existing theory and data.

Why it matters

Data‑scarce domains (e.g., high‑energy physics, climate modeling) often lack clean, labeled datasets. Traditional symbolic regression struggles when the search space is huge and the underlying dynamics are noisy.
AI‑Hilbert expands the search space by coupling continuous polynomial families with a Bayesian‑style pruning of implausible terms, delivering equations that are both interpretable and generalizable.

Bottom line – AI can now act as a “virtual mathematician,” surfacing equations that push the frontier of scientific theory while keeping the output human‑readable and testable.

2. Smarter Literature Mining with SciLitLLM

Reading the literature is the backbone of any research program, yet the semantic gap between disciplines hampers existing LLMs. SciLitLLM, a family of models built on a continual‑pre‑training + supervised fine‑tuning pipeline, directly addresses this problem.

Key capabilities

Domain‑aware embeddings that capture jargon from chemistry, biology, nanomaterials, etc., without catastrophic forgetting.
Ability to extract targeted facts (e.g., “list all catalysts reported with >95 % yield under 25 °C”) and produce concise, citation‑ready summaries.
Human‑in‑the‑loop validation layer: researchers verify that hallucinations are filtered before conclusions are drawn.

Limitations – The model is powerful but not a substitute for critical appraisal; it still requires domain experts to curate outputs and guard against subtle misinterpretations.

3. LLM‑Generated Research Ideas (and Their Unexpected Novelty)

A Stanford‑led pre‑print experiment pitted human‑only idea generation against LLM‑generated proposals that were subsequently re‑ranked by expert reviewers.

Result: The top‑ranked LLM ideas were judged significantly more novel than those produced solely by the human panel, even though feasibility scores were comparable.
Implication: Large language models can break cognitive lock‑in, surfacing unconventional connections that traditional pipelines often overlook.
Caveats: Novelty does not guarantee practicality; further validation and feasibility modeling are required before moving to grant proposals or experimental testing.

4. The Common Thread & What Still Needs to Happen

All three examples share a common prerequisite: they are research‑grade tools, not off‑the‑shelf plug‑ins. Realising their full potential demands:

Customization – fine‑tuning on discipline‑specific corpora or data pipelines.
Trust & Transparency – rigorous validation, explainability layers, and community benchmarks.
Institutional Investment – compute resources, training programs, and integration into research workflows.

In short, AI is moving from a supporting calculator to a co‑investigator, but the transition hinges on sustained collaboration between technologists, domain scientists, and research administrators.

Looking Ahead

The convergence of symbolic equation generators, domain‑aware literature models, and ideation‑focused LLMs suggests a new research ecosystem where AI amplifies every stage of the scientific method—from hypothesis birth to experimental validation. When these tools become as routine as a statistical package, we can expect a acceleration of discovery across fields that have traditionally stagnated under data scarcity and human cognitive limits.

Stay tuned to Diagonalising for deeper dives into each tool, practical implementation guides, and interviews with the scientists who are already piloting them.

Innovation capital: Is the tide low?

Wed, 29 Jun 2022 00:00:00 +0000

Half a year into 2022 central banks are poised to keep raising interest rates, supply chains are hobbled, and a war is raging in Europe. As this harrowing mix turned markets tumultuous and zapped investors’ confidence, what does it mean for VC-backed investment?

In this , Christoph Feest and I argue that trends in policy and digitalization feed an undiminished appetite and need for venture backing, leading to increased, more-broadly sourced and more widely-distributed investments.

Digital Transformation | Giulia Solinas

Building Agents in Bob with a Software Spec Driven Approach

Building Agents in Bob with a Software Spec Driven Approach

Why Spec Driven Agent Development Matters

The Bob Skill Pipeline

Step 1: Start with solution-architect

Step 2: Convert Architecture into SOPs with sop-builder skills

Step 3: Generate the wxO Solution with wxo-builder skills

Step 4: Audit and Document with wxo-analyzer skills

A Practical End-to-End Flow

Best Practices for Spec Driven Agent Work

What This Changes

AI for Science

1. AI as a “Hilbert” for Equation Discovery

2. Smarter Literature Mining with SciLitLLM

3. LLM‑Generated Research Ideas (and Their Unexpected Novelty)

4. The Common Thread & What Still Needs to Happen

Looking Ahead

Innovation capital: Is the tide low?

Step 1: Start with `solution-architect`

Step 2: Convert Architecture into SOPs with `sop-builder` skills

Step 3: Generate the wxO Solution with `wxo-builder` skills

Step 4: Audit and Document with `wxo-analyzer` skills

1. AI as a “Hilbert” for Equation Discovery

2. Smarter Literature Mining with SciLitLLM

3. LLM‑Generated Research Ideas (and Their Unexpected Novelty)

4. The Common Thread & What Still Needs to Happen