CampusPathAWS

CampusPath turns a student's goal into a term-by-term plan built from the university's own resources: every step explained, every action logged, and closes the loop for the school.

Comment

** 【Demo passcode：OceanMeetsTheSky! 】**

Inspiration

We started from a number: 93. That is how many official pages at one university (HKUST, our demo case) publish opportunities a student might care about. School pages, lab pages, club pages, partner-company postings, most of them changing every week. Add a catalog of 1,534 courses and a careers noticeboard that updates weekly, and a student already carrying a full course load cannot keep up. When they do spot something, it clashes with the timetable, or it is the wrong fit, and the one that actually mattered slips past.

What a student needs is someone to pull the university's resources into one place, work out which skills their target career actually calls for, and turn that goal into "here is what you do this term". Out of everything the campus publishes, that someone picks the opportunities the student is eligible for right now and that close a real gap on the way to the goal. It plans around them, checks each one against prerequisites and the real calendar, and writes it into the schedule only after the student says yes. After the activity, the student jots down a reflection, and the system remembers what they prefer, so it reads them a little better each time. That is ordinary personal admin, done end to end, which is what the Everyday Agents track asks for.

What it does

CampusPathAWS is a growth-planning system a university deploys for its students. Students use it. The university runs it, plugging in its registrar, career centre and each school's feeds. It serves five kinds of student: job-bound, going on to further study, starting a company, keeping an interest alive, or still exploring. For this hackathon, the demo follows the first group end to end: undergraduates with a clear career goal who are heading straight into work.

The student side is one loop in eight steps:

  1. Growth profile. The student connects the registrar, authorises their calendar and uploads a résumé. An agent reads it into structured facts, each marked pending. Nothing enters the profile until the student accepts it.
  2. Two goals, decomposed. A main goal and a secondary one. The goal agent pulls real job requirements and splits them into hard and soft conditions, each tied to its source. Evidence only, no ranking.
  3. Matching. Every campus opportunity is scored against that gap. Each card shows one of four eligibility states and the reason underneath: why this one, and why not that one.
  4. The plan. Only one agent, A5, is allowed to make trade-offs. It offers three intensities, puts electives and activities side by side, and moves preparation forward: a language exam a year ahead, a major competition a month ahead. What it hands back is a proposal.
  5. Calendar. Only approved items land on the week. A clash with a class is computed by a deterministic capacity service, not guessed by a model. Sleep, meals and buffers are protected time the planner cannot touch.
  6. Action. The student approves item by item, and every write leaves a consent receipt. Crossed-out items join a decline list the agent avoids next round. The QR code issued with the approval checks them in on the day.
  7. Reflection. After an activity or an advisor meeting, the student writes notes and rates it on four dimensions. The advisor's key advice unlocks only once the reflection is saved.
  8. Evidence. The reflection becomes a growth-record entry and a new set of profile proposals. The loop closes here, and the next plan starts from a sharper profile.

The institution side is the other loop. Club leads and lab professors submit activities. The Career Center console manages 93 official sources, change-detected by content hash, fetched daily or on one click. Only after staff approve does an item reach students. Check-ins and anonymous ratings flow back automatically, and the console reports weekly, monthly and by term, so the university can see which resources worked instead of guessing.

Two guardrails sit entirely outside the agents. The first is wellbeing. Sleep debt and overload are judged by fixed thresholds and fixed scripts, and when they trip, the student's tutor or counsellor is contacted directly, so an AI is never the one deciding whether a student is in trouble. The chain runs from a reminder, to a screening scale, to a counsellor booking, to an emergency button that skips the queue. The second is for international students, who get their own resource pack (visa, language level, policy) that every agent has to carry into its judgement.

How we built it

Six agents (A0 to A5) built with the Strands Agents SDK sit on top of nine deterministic services that never call a model. The agents are the only code allowed to call one. The services own every judgement a plan depends on: prerequisites, capacity, wellbeing, eligibility. Every plan item a student sees carries a validation_id the rules engine actually issued, and the API rejects any item that arrives without one.

The Strands specifics follow.

One model factory, one Model interface. strands_models.py builds a Strands BedrockModel on Amazon Nova Pro (amazon.nova-pro-v1:0, us-east-1) by default, plus a hand-written ScriptedStrandsModel that implements Model.stream() deterministically for zero-cost CI.

Hard rules live in hooks, not in prompts. ToolWhitelistHook runs on every BeforeToolCallEvent and sets event.cancel_tool for any tool not on that agent's whitelist, so the call is refused before it executes. PromptHygieneHook runs on every BeforeModelCallEvent and raises if the outgoing messages contain anything shaped like a calendar OAuth token or a bearer header. Both hooks attach to every Agent object, whatever the backend.

Tools go to exactly one agent. A4, the opportunity scout, is the only agent with tools: read_source and emit_opportunity_draft, wrapped as Strands PythonAgentTools. It can draft an opportunity for a human reviewer. It can never publish one. External page content enters only as a user-role message, never the system prompt.

Structured output with a repair loop. A5 calls structured_output_async(PathwayDraft) for up to three rounds. Each round the draft is re-validated against the rules engine and the violation list goes back to the model as a user message. A1 uses the same call to turn reflections into typed, anonymous feedback.

AgentCore is the runtime. agents/cloud/agentcore_app.py is a BedrockAgentCoreApp entrypoint that whitelist-routes agent names and rejects unknown ones. The deployed runtime reports READY, and GET /v1/ops/agents returns the runtime, backend and SDK version read from importlib.metadata at request time, not copied into a doc.

Around that: a Next.js 16 PWA in English, Simplified and Traditional Chinese; a FastAPI service on Cloud Run with contract-typed endpoints and RBAC; Firestore for state; a read-only MCP connector for Moodle; OpenTelemetry traces.

Challenges we ran into

The hackathon clock was the main constraint. Two of the five student groups, international students and students whose next step is further study, do not yet have flows as complete as the job-bound path. Rather than rush them in half-finished, we left them for a later round.

Accomplishments that we're proud of

Every model call in the request path is a Strands Agent invocation. An AST-level scan confirms no direct model-SDK import remains in the agents package.

Six architectural invariants set before the hackathon came through the port unchanged: only A5 makes trade-offs; the wellbeing chain never touches a model; calendar tokens never reach a model; A4's whitelist is exactly two tools; every plan item needs a validation_id issued by the rules engine; student-to-institution feedback is structured and anonymous only. Each one now maps onto a Strands construct rather than a sentence in a prompt.

Every guard ships with a known-failing sample. Remove the hook's cancellation, or the model-type assertion, and a specific named test goes red.

The semantic plane runs on Bedrock AgentCore Runtime, and the invocation logs in the demo were recorded live.

A complete product: three languages, PWA, the real course catalog, both loops, both guardrails, one continuous demo take.

What we learned

In a multi-step agent architecture, the number of agents has to be weighed against how the work is split. More agents is not better. Each one should own a judgement none of the others make, or it is only adding hand-offs.

On the pitch: "who it is for" was harder to say well than "how it works". Spending the first minute of the video on the problem, the audience and the stakes made the technical beats easier to follow.

What's next for CampusPathAWS

Build out the flows for international students and for students going on to further study, so that undergraduates, master's students and PhD candidates all get real use out of the platform.

Use AgentCoreMemorySessionManager for A0's session state, and an AgentCore Gateway that exposes the rules engine as an MCP tool other agents and products can query without copying its logic.

Onboard a second university. HKUST is only the demo case. The platform runs on whatever registrar, career centre and school feeds a campus plugs in. Proving that outside our own campus is the next milestone.

Built With

  • amazon-bedrock
  • amazon-nova
  • bedrock-agentcore
  • docker
  • fastapi
  • firestore
  • google-cloud-run
  • mcp
  • next.js
  • opentelemetry
  • pwa
  • pydantic
  • python
  • react
  • strands-agents
  • typescript
Share this project:

Updates

Submission history